What is applicable static analysis

Static analysis refers to the review of code without executing it. Such review may be done as a phase of a coding project, or naturally occurring when the code is handed to a new programmer (That new programmer may also be yourself, six months later). In both case, the goal is to spot defects by reading the code, understanding it and finding impossible situations.

Unlike testing, code review happens after the code is written, because, of course, there is nothing to review until it is written. However, written code carries more than the eye can see. It is not possible to review the code without taking into account two different aspects : its architecture and the specifics.

Code architecture

The code architecture is a framework of rules that organizes the code. For example, design patterns or MVC paradigm helps segregate various parts of the code, and brings some clarity to the way things are carried out : Controler, Model and View all have distinct tasks . Frameworks in general, provide a lot of such architecture.

Code architecture is difficult to read in the code itself. It requires prior knowledge : indeed, before using any framework, one has to read its documentation, learn from a tutorial, and then start coding. The paradigm shifts from calling the ‘echo’ command to writing a .phtml file. Static analysis tools can’t learn from the code that some classes are controller or not : they must know it before.

Project specifics

There are also architecture rules that specific to a project. File hierarchies are usually very different from one project to the other (WordPress file structure, Magento file structure, Code Igniter). Folders are used to put cache, temporary files, modules, modules for V1 or V2, or tests. This has to be learned and is not reusable from one project to another (or, from experience, very little).

Other project specifics are derived from business logic, such as data format or algorithms. And some of the architecture also is derived from it, such as helpers or related REST services.

Generic defect

Finally, there are the general defect. Those are code issues that lead to bugs, without any link to buisiness logic or project-related rules. That may be a classic misunderstanding of the language, or a quick-hack situation.

The main difference with the previous issues is that the set of rules is related to PHP, for which one may find various sources of recommendations. Learning this is already done and should not be specific to a project or any architecture choices.

As a summary, the table below sums up the various kind of code and defects that static analysis will find :

	Visible in Code	Visible in Architecture
Generic defect	Issue that will be find with static analysis.Dangling reference error	Static analysis finds traces, but cannot conclude. It needs to know the architecture.Only Model makes queries to the database; only template has HTML (if applicable)
Project specific	Once the specific rules are defined, it may be find with static analysisA phone number as a format of : (\d\d)-(\d\d)-(\d\d)-(\d\d)-(\d\d)	Requires specific rules and architecture visionPhone numbers are stored in CHAR(10) column, without separation (i18n is applied in the template)

Applicable Static Analysis

One of the main limitation of static analysis is the listing of enforceable rules. Having a set of rules for PHP, such as PSR, clearPHP or object Calisthenics provides a good general reference.

The next step is to provide the specific rules for a project. This covers :

• Cherry picking rules from other references
• Helpers methods
• Data format (date, phone, ISBN, for parsing, validating, displaying and manipulating)
• Configurations (names, definitions, accessing)
• Storage structure (link between classes and storages, compulsory object for storing)
• Algorithms (CC validation, VAT number validation, )
• Business logic
• Object broker (never call db api, always use this object…)
• Project do and don’t (add a personal touch)

Most often, those rules are being build along the way. Collecting them as soon as possible allows everyone to write legit code. It also allows for inclusion in a static auditing tool, that will watch the code and provide systematic feedback on the application of the rule. As long as the coding standards are not known, they can’t be searched and applied.

Object Calisthenics

As a example, here is the Object Calisthenics programming exercises distributed above the above matrix. As this philosophy is not PHP-specific, there are no ‘Generic Defect’. Try it with your own project.

	Visible in Code	Visible in Architecture
Generic defect		Don’t Use The ELSE Keyword Only One Level Of Indentation Per Method Keep All Entities Small No Classes With More Than Two Instance Variables No Getters/Setters/Properties
Project specific	Wrap All Primitives And Strings One -> Per Line	First Class Collections

 

Don’t Abbreviate : coding convention. Not covered here.