Why standards are so important in development

Let's talk about the differences between standardized code and messy code. In my opinion, what differs a good developer from another is the way you take care of the code you're writing.

In the course of time, development agencies have less time to deal with the projects. They need to guarantee the quality and deliver projects in less time, and this could be the factor between getting the pitch or not. Sometimes the agencies assign more than one developer to take care of the project, even though knowing that, there are developers who don’t take care of his code and don’t think as a team.

If you're a developer and works in a team, you have to think on how good would it be if you get a code where you can easily understand and start working immediately.

In this article, I will use the PHP language and the PSRs guide for Coding Style to exemplify and identify the differences between a clean and understandable code, and a messy code.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Refactoring: Improving the Design of Existing Code, 1999.
Martin Fowler.

Clean Code

So let's start with the clean code section. Wait… What does it mean?
I would say that a good definition for clean code is that one which the developer could clearly and quickly understand the objective and the functionality. Let's move for the first example of clean code:

On the code above we can see that our clean code have more lines than the messy one, however with quick comments and with a pattern of return as soon as possible, we reduced the complexity, making it more understandable and easier for other developers to give maintenance.

PSR-2 Coding Style Guide

In PHP we have a group called PHP Framework Interop Group (PHP-FIG), their intention is to talk about commonalities to find ways we can work better together.

At the moment the PHP-FIG has 8 Accepted PSRs, but for me, the most important is the PSR-2 because it is a guide for Coding Style.

Before start talking about the definitions, check below an example using PSR and another one without:

You have to agree with me that even with slight changes in the code like using the camel case instead of underlines and add spaces between parenthesis and braces, the code seems clear and understandable.

In the PSR-2 as the name already says, it’s a guide to help us and define for us some standards to write a clean and understandable code. Below I will write quick notes about each section of the guide.

1. General
   This topic says about basics, files and conventions to prepare your workstation to write clean codes.
2. Namespaces and Use Declarations
   Please give particular attention to this subject because the namespaces you build for your library will be used by other developers, try to create namespaces related to the files that will be inside that. For example, I want to add a service to my namespace, so I will create a namespace called “Services/” and not “Controllers/”.
   Now probably you’re thinking: I’m not stupid, for sure I will do that.
   But unfortunately, I have to say that I already worked in projects that the namespace was called “Classes/”.
3. Classes, Properties and Methods
   The most important part of this guide. You have to think out of the box in your classes, properties, and methods. To think only about its functionality isn’t enough for some cases. For example, You have to write a method in a class to iterate all items from the shopping cart. The first thing you have to think is: Do I have to instance my class to an object to call the method? Or can I use my method statically?
   For sure if you have the basic knowledge of Objects Oriented Programming you will know that and will do a great job.
4. Control Structures
   Please let the "if" breathe. You cannot imagine how I feel when I see codes without any space between the "if" statement and the parentheses.
5. Closures
   In my opinion, the application is the same as in the methods. So quite simple here.

Even though exemplifying the things here with the PSR, you don’t have to follow a guide or wait for a group, to start developing with quality. I know that sometimes you’re focused on the delivery or doing a hard code where you only expect that it works, but by doing a commented and clean code you will save time in the next maintenance you or your college will have to do. For each statement of your code, you have to think: Is it clear and understandable enough? Can I reduce its complexity? Is it possible for my colleges to continue working on it afterward? Can I split large functions with a lot of responsibilities for shorter methods with lower responsibilities?

Finally, I would like to say thanks for being until here, and I hope this short article helped you somehow to improve your coding style. See you in the next article.