Tomas Votruba has written up a new post to his site sharing an update to a project he has to make it easier to enforce various coding standards in your application's codebase. In this update he talks about the Easy Coding Standard project's v4 alpha that includes a "clean" Symfony standard with support for Yaml and Services.

I wrote about news in Easy Coding Standard 3 a while ago. EasyCodingStandard 4 is not released yet (still in alpha), but soon you'll be able to use all the news I'll show you today.

And what are they? Neon to Yaml, semi-static to Services, customizable caching, even simpler skipper, short bin and more.

He breaks the new features down into a list of six updates:

• Configure Caching Directory
• Skip Anything, Anywhere
• Short vendor/bin/ecs is the King
• DI Migration Finished: From Neon to Yaml
• From Semi-Static Checkers to Services as First-Class Citizen
• Good Bye Neon Class Autocomplete Or not?

For each there's a brief snippet showing how to configure it a brief description of what it enforces.

In a post to his site Sarfraz Ahmed shares a command that can be used in a Laravel application (via artisan) to clean up unnecessary files from packages that you may have installed.

When installing composer packages, they come up with lot of useless files and folders such as .git, tests, readme.md and more. When project becomes bigger with many packages, this junk takes considerable disk space. Since I work with Laravel framework most of the time, I created a command that allows me to automatically delete all these junk files whenever I happen to install or update composer packages.

He lists out the patterns the command matches by default including "tests", "readme*" and "*.log". There's a long list of items and, having worked with several packages, I can tell you that most of the files caught by this need to be removed anyway. He has posted the code on GitHub and provides some examples of the command line calls and how it can be called automatically.

Another package that does something similar but allows the package itself to define the files to remove is the composerclean library that is executed as a Composer command rather than an artisan command.

Jason McCreary has continued his series looking at writing "clean code", providing a few helpful hints you can integrate into your daily development work. In part two he goes a bit "deeper" and talks about grouping and encapsulation.

In Part 1 of Writing Clean Code I outlined three simple practices of formatting, naming, and avoiding nested code. All in an effort to improve code readability.

In Part 2, I want to go a little deeper and cover grouping. When I say grouping, I’m really talking about the Object Oriented Programming paradigm of encapsulation. Whether we group the code into a function or a class is often not important. What is important is did we improve the readability of the code.

He starts off by describing the goal of this grouping and lists three motivations for using it as a part of your application's architecture:

• Improving communication
• Couple data
• Organizing code

For each, he includes a brief summary of the topic and some code examples illustrating it in action where appropriate.

The Laravel News site has a new post sharing the application of "clean code" concepts to PHP with a few handy examples. These suggestions are pulled from this set of guidelines.

Clean Code PHP (jupeter/clean-code-php), is a guide based on the book Clean Code: A Handbook of Agile Software Craftmanship, a classic programming book about writing maintainable code by Uncle Bob Martin.

The clean-code-php guide is inspired by a JavaScript adaptation, clean-code-javascript with PHP-specific features.

Examples they show in the post are around unneeded context, the number of function arguments and functions doing more than one thing. They also include a word of warning about these and other "clean code" suggestions, pointing out that they're mostly matters of opinion and not hard and fast rules to enforce every time. The post ends with links to two "clean code" resources for more reading: "[Clean Code]"(https://amzn.to/2wFCjo4) and "The Clean Coder: A Code of Conduct for Professional Programmers".

In a recent post to his site Marco Bunge offers some suggestions on how to write good application logic in a "clean, testable and reusable" way.

Web based enterprise applications are often accessible via different user interfaces through protocols like HTTP, Sockets, RPC, CLI. The Model-View-Controller is still present as a user-interface pattern. But requests and responses needs to be handled in the way of their interface requirements.

We don’t want to write the same logic for each required interfaces. Furthermore we don’t want to test and maintain code for each required interfaces. We want to write, test and maintain reusable source code at a central point of the application eco-system.

He then talks about the ideas behind the "three-teir architecture" and how this structure can be used to split logic into layers: presentation, logic and data. He mentions domain driven design as a development method to help achieve this structure and his meaning of the word "clean". He then gets into the implementation of this structure, defining the major pieces of functionality for each tier (with code for each included). He ends the post with some suggestions of points for additional reading about things like presenters, the ADR pattern and the "Inversion of Control" principle.

In a new post to his site Jason McCreary makes a case for writing clean code in your development processes. He makes three main suggestions of practices you can integrate into your workflow to help make the code you write cleaner.

I noticed [legacy codebases] all suffer from the same fundamental issue - inconsistency. Often the result of years of code patching, large teams, changing hands, or all of the above.

This creates a problem because we read code far more than we write code. So as I read a new codebase these inconsistencies distract me from the true code. My focus shifts to the mundane of indentation and variable tracking instead of the important business logic.

In my experience, I find I boy scout a new codebase in the same way. Three simple practices to improve the readability of the code.

His three suggestions for improving the overall code quality center around standardized formatting rules, consistent naming practices and avoiding nested code. He uses an example piece of code to help illustrate these recommendations with explanations for each.

In a recent post to his site Jeroen de Dauw looks at some of his own work and ideas around implementing clean architecture in PHP-based applications. The idea behind "clean architecture" is a focus on separation of concerns and dividing the systems into "layers" with contained logic in each.

Both Domain Driven Design and architectures such as the Clean Architecture and Hexagonal are often talked about. It’s hard to go to a conference on software development and not run into one of these topics. However it can be challenging to find good real-world examples. In this blog post I’ll introduce you to an application following the Clean Architecture and incorporating a lot of DDD patterns. The focus is on the key concepts of the Clean Architecture, and the most important lessons we learned implementing it.

In his post he looks at a real-world application (the Wikimedia Deutschland fundraising software) and how Domain Driven Design plays into the "clean" structure. He then walks through code examples, directory structures and lessons learned along the way (including bounded contexts and effective validation).

On the Laravel News site a tutorial has been published showing you how to install Bourbon and Neat with Laravel's "elixir" functionality (a wrapper around the popular Gulp installation tool for Javascript and CSS library handling.

Laravel Elixir is a wrapper that simplifies working with Gulp, it makes compiling, concating, minifying and versioning your JavaScript and CSS files very fluent and easy.

Because many projects using Bootstrap, when you start a new Laravel project, you will find that it is included by default as a basic starting point, but Laravel does not dictate which JavaScript or CSS frameworks you should use. One alternative is Bourbon and Neat created by thoughtbot.

Bourbon is a mixin library for Sass and Neat is a Bourbon addon for creating semantic grids. In this tutorial let’s take a look at how to setup these tools with Laravel Elixir.

They start with a brief overview of the Bourbon tool, showing how it helps to reduce the amount of duplicate code in your source files. There's also a bit about Neat, a responsive grid library that makes it easier to keep your layout "clean and semantic". With those defined they get into the installation of these two packages with two different approaches:

• First installing Bourbon/Neat via npm then importing them in the SASS config
• Or installing them via npm, edit the Gulp configuration then import them relatively

With either of these methods in place the Elixir tool can then run the compilation right alongside the other sources and push the resulting CSS out the other side including the Bourbon and Neat functionality.

On the Intracto blog there's a new post from Joeri Timmermans talking about writing clean code with some good suggestions you can easily incorporate into your current processes.

So you came here to save a kitten? That's wonderful, but the real reason we're both here is to talk about clean code. In this blog post I'll be sharing some of my personal experiences and tips. But before we dive into the tips and tricks part, let's talk about what we, as developers, do and why we do it.

He touches on several topics including:

• Best vs Fastest
• Reading vs Writing
• File and Folder Organization
• Naming [conventions and clarity]

He also makes the recommendation to "return often", keep things DRY and makes a few recommendations of PHP-specific tools that can help.

While not specific to PHP (the examples are in Ruby, in fact) this new tutorial on the Toptal.com blog has some good information and suggestions around the use of exceptions in your applications.

Exceptions require special treatment, and an unhandled exception may cause unexpected behavior. The results are often spectacular.

Over time, these errors, and countless others [...] contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming; they exist to make our software better. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

They start by talking about why exception handling is a good thing and some common practices to help make them more manageable. They suggest that good exception handling can also help make your code more maintainable, extensible and readable in the long run. He suggests creating your own kind of exception hierarchy (more possible in PHP 7) and using them to get more specific on the type of exception that was thrown. He recommends not "rescuing" exceptions more than needed (in PHP this is try/catch) and that it's okay to defer the handling for the exception being thrown and not deal with it right away.

He also reminds you that not all exceptions need handling in your own code (sometimes it's up to the user) and that following conventions on naming can help end users better understand why there's an error. Finally, he recommends logging exceptions as they're major errors in your application, not just data problems or smaller bugs.