When programming, I devote a part of my time to review the code. Of course, there is the necessary review when a bug arise, but I’m talking here about self-review. It feels always good to re-read fresh code, make sure I didn’t forget anything, may it be security, performance, recent PHP or framework recommendations. When this is done, I get a good feeling of fulfillment, and I trust better my own code.
Reviewing one’s code may be done in a variety of ways. One of the best way is to have someone else read it. Indeed, preparing the code to be reviewed is, by itself, a way to make it better : when one knows that the code will be read by someone else, there is a big incentive to review it. No one wants to look like a fool and let an obvious mistake slip past.
And when no one is available to scan, there is something that is always available : a static auditing scanner. This piece of software will examine the code without executing it, and will return a number of recommendations to improve it. This is the closest the coding experience, as it will check the code, and not treat it as a black box. And it helps a lot to track the daily small mistakes.
Code base gets larger
Static auditing tool being a piece of software, it comes with several notable advantages. The first is the time spent auditing. When the code base get large to very large, it gets really hard for anyone to read it all. Automated tools will also takes longer time to process larger code base, but they will still do it faster and in a more focused way than any human reviewer.
Code base is modified by many
Also, when many developers happen to be working on the same code base, this generates a long history of fixes and updates, on a daily basis. It quickly gets long to review, let alone check its impact on the non-modified code.
Experienced teams then set up coding conventions and lists of recommendations for developers to follow. They are sometimes called best practices, or mantras when they are few enough. This is good to provide a familiar background to the whole development team. It also makes it easier to check code quality and compare one piece to the rules.
Reviewer fatigue
Besides the sheer size of the project, large code base also introduce us with reviewer fatigue : reviewing the same or almost same code several times means that feedback seems to loose any value. Sometimes, as soon as two reviews are sufficient for it to appear. This is where automated reviewing helps : a piece of software will never get bored.
Best practices evolution
On top of the auditing process, the recommendations are on constant evolution. In-house conventions are often expected to be fixed and never changing, but the truth is that is is never the case. New one appears, old one disappear and existing ones are changed. In PHP 5.4, htmlentities() is switching its default encoding from ISO-8859-1 to UTF-8, and that changes old time habits of using the default value of the third argument. In PHP 5.6, it will change again from UTF-8 to default_charset. Such changes may come from PHP, the framework used on top of PHP, may it be internal or open source, or simply the chosen tradition in the company.
Making yourself code better
Finally, auditing, statically or not, provides feedback on how to improve your coding style. Spotting situations in you very code and alternative approach turn some high level discussion in the community into very pragmatic suggestion directly within your code. It is then easier to understand theory, and decide if it is worth it or not. It actually happens to be an epiphany to some.