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 Tomáš Votruba shares what he sees as a "bulletproof" event naming scheme for use with the Symfony event dispatcher component.

I wrote intro to SymfonyEventDispatcher and how to use it with simple event.

But when it comes to dispatching events, you can choose from 4 different ways. Which one to choose and why? Today I will show you pros and cons of them to make it easier for you.

He then breaks up the remainder of the post into the four suggestions, each with code examples and brief descriptions:

• 1. Start with Stringly
• 2. Group File with Events Names as Constants
• 3. ...Constant Names in Particular Event Classes
• 4. Class-based Event Naming

For each he also includes some "pros" and "cons" to help you select which one might work best for your usage. He ends by taking things "a step further" and sharing integrating a suggestion to remove an argument and simplify the code.

In the latest post to his site Stefan Koopmanschap offers some advice on when to use exceptions and when to avoid them (the result of a recent Twitter discussion).

I recently found myself in a discussion on whether or not exceptions could be used to control program flow in software (specifically in PHP applications). That triggered me to post a tweet:

Exceptions should not be used to control expected application flow. Discuss.... @skoop

This triggered quite a bit of discussion, which gave me a lot of input on this topic. I want to thank everyone who joined that discussion for their input, which was really valuable. In this blogpost I'll do a summary of the different arguments in the discussion, and give my opinion on this.

He goes on to define the term "program flow" and how that relates to the idea of using exceptions to control it. He then talks about naming things, the "intent" of your code and how the right names can make your code clearer and easier to maintain.

In a new post to his site Nikola Poša has suggested some testing conventions he's worked up over his time in development across projects.

Testing is an essential aspect of development, and test code should be treated the same way with regard to defining and using coding conventions and standards.

This time I would like to share few conventions that I follow when writing unit tests in particular, some of which I adopted only recently.

He breaks it down into three main sections:

• Structure (file locations and namespacing)
• Naming (files and testing methods)
• Arrange-Act-Assert with exceptions and test doubles

Example code is included showing the concepts and implementation of the suggested convention, just to name a few.

In a new post to his site Leonid Mamchenkov talks about feature flags, a handy tool you can use in your application to enable/disable features and or risky changes in your code allowing you more production-level control.

Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations. It touches on the following: Command-line flags, with the link to gflags, A/B flags, Dynamic flags [which are more difficult] and more complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those. [...] These days, something more robust than that is necessary for some of the projects at work. Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel.

He talks about some of the challenges that he had in his own feature flag implementation including naming of the flags and where the flags should be placed. He then links to the PHP Feature Flags site and various PHP libraries that implement feature flags slightly differently and cover cookie-based, IP-based and URL-based features. He ends the post by pointing out that the lack of feature flags in any complex application is usually considered toxic when it comes to being able to scale an application correctly.

Alain Schlesser has written up a new post for his site sharing some of his suggestions for structuring your PHP exceptions including localization, catching them and using them with named constructors.

I seem to constantly work on improving my habits regarding the use of exceptions. I think it is an area that I haven’t yet fully explored, and it is very difficult to find anything more than very basic explanations and tutorials online. While the consensus is to use exceptions, there is very little information on how to structure and manage them in a larger codebase. The larger and more complex your projects become, the more important it is to start with a proper structure to avoid expensive refactoring later on. Your client will surely be thankful!

In this article, I want to talk about the way I currently set them up and use them in PHP, in the hopes to spark some discussion on the topic and get further feedback.

He starts with a few thoughts about why even using exceptions is a good idea (over just errors) and how to build on the included SPL exception set. He then gets into the suggestions about:

• naming conventions
• using named constructors to encapsulate logic
• working with localized exception messages
• catching exceptions

He ends the post by suggesting one last piece that can help make catching and handling exceptions easier - a centralized handler, something potentially like BooBoo from The PHP League.

On the SitePoint PHP blog Tobias Schlitt has an article posted that tries to answer the question "is refactoring for aesthetics worth it" for most development groups out there.

Most development teams want to get their codebase into a better, more maintainable state. But what definition of better should be chosen? In many cases, it is not necessary to dig deep into Domain Driven Design (DDD) to achieve this goal. Sometimes, it's even counter productive. But one of the most basic collections of principles can help each team a lot already: Clean Code.

The Clean Code book by Robert C. Martin summarizes many simple and advanced improvements to get better, understandable, and therefore more maintainable code.

He goes on with a bit of example code, showing a getJobs method that has room for improvement. He makes recommendations on cleanup steps like: renaming variables for clarity and breaking up code more visibly based on functionality. He then talks about the "methodology of refactoring" and how to take "baby steps" in your updates rather than major jumps. He ends by pointing out that refactoring for "beauty" sake isn't a good idea nor is doing it without a sufficient level of automated testing to ensure changes didn't break the application.

The SitePoint PHP blog has a new tutorial posted showing you how Laravel Facades work and how they ("Facades") can be used in other framework types.

The Facade pattern is a software design pattern which is often used in object oriented programming. A facade is, in fact, a class wrapping a complex library to provide a simpler and more readable interface to it. The Facade pattern can also be used to provide a unified and well-designed API to a group of complex and poorly designed APIs. The Laravel framework has a feature similar to this pattern, also termed Facades. In this tutorial we will learn how to bring Laravel’s "Facades" to other frameworks.

He starts off by looking at how the Laravel framework has implemented facades through out the entire framework. He includes examples of using these facades (like the App to make a new object instance) and how the base Facade class is structured to make it work. He covers some of the basic features of the classes that extend this base and how they're aliased in the Laravel code/configuration. He then gets into using this same sort of "facade" approach to other frameworks, specifically in an app based on the Silex microframework. He lists some of the requirements and shows how to pull in the base Facade class to extend. He also integrates the aliasing code and configuration to make it simpler to use the short names rather than full namespaced versions of the classes.

Paul Jones has a post to his site looking at SQL schema naming conventions and some of his own thoughts on the matter. There's a lot of different camps of thought around naming, much less database ones, and he makes a few suggestions learned from his experience over time.

Several weeks ago I asked on Twitter for SQL schema naming conventions from DBA professionals. (I’m always interested in the generally-accepted practices of related professions; when I can, I try to make my work as compatible with theirs as possible.)

I got back only a handful of responses, representing MySQL, PostgreSQL, and DB2 administrators, really not enough for a statistically useful sample. Even so, I’m going to present their anonymized responses here, because they led me to work I had not previously considered at length.

He asked about things like singular vs plural names, primary key choices and naming of association tables. The uses the rest of the post sharing the responses he got from his questions with a good range of responses representing both sides of each question. He wraps up the post looking at what these answers mean to the average developer and the answers that Joe Celko and Simon Holywell have to say on the matter.

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

• the overall style of the code
• the structure of the application (directories, libraries used, etc)
• naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).