Monday, July 10, 2017

Enforcing Development Teams write Good Code(PSR 1 and 2 Compliant)

If we look at this  relatively old graphic from Zend.com or at other infographics on sites like https://trends.builtwith.com/framework/PHP or we understand that more than 80 percent of websites today including Facebook, Wikipedia, Tumblr and WordPress are using PHP in some form.

The focus for any business is on delivering more robust Apps faster the key being maintainability of the code. Following Agile methodology we keep making many parallel changes to the code base as we go. All this is only possible if we follow certain standards in the way we code.

A few well know PHP projects like Zend, Symphony, Yii, Cake, Slim, Drupal, Magento etc. got together and formed FIG(Framework Interoperability Group). PHP-FIG as it's commonly known have worked on a list of PSR's. More commonly known as PHP Standards Recommendations.

The Accepted list of PSR's include
1 - Basic Coding Standard
2 - Coding Style Guide Paul
3 - Logger Interface
4 - Autoloading Standard
6 - Caching Interface
7 - HTTP Message Interface
13 - Hypermedia Links
16 - Simple Cache

Our focus for this article will remain on PSR 1 and PSR 2. How to ensure that the Basic Coding Standard and the Coding Style Guide are followed by development teams.

A quick look at PSR 1 shows

  • Files MUST use only <?php and <?= tags. 
  • Files MUST use only UTF-8 without BOM for PHP code. 
  • Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0, PSR-4]. 
  • Class names MUST be declared in StudlyCaps. 
  • Class constants MUST be declared in all upper case with underscore separators. 
  • Method names MUST be declared in camelCase.
  • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
PSR 2 says
  • Code MUST follow a “coding style guide” PSR [PSR-1]. 
  • Code MUST use 4 spaces for indenting, not tabs. 
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less. 
  • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of use declarations. 
  • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body. 
  • Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body. 
  • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility. 
  • Control structure keywords MUST have one space after them; method and function calls MUST NOT. 
  • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body. 
  • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

First step as usual is approaching the team and sharing the benefits of following PSR which they would most probably already know. Post which we find delays citied as more time is needed to achieve and then check during code review. Everything that goes wrong will somehow be due to this enforcement including logical errors.

Time is money and any standard should not add to timelines so a very Quick solution will be to configure IDE's.

Most of the common IDE's have ready solutions,
Net Beans - https://github.com/allebb/netbeans-psr-formatting
Sublime Text - https://gist.github.com/mikefrancis/63436f1cb94ec31ce31f
PHP Storm - In built, use link to activate - https://www.matthewsetter.com/enforcing-psr1-and-psr2-with-phpstorm/
Eclipse - Can be fixed within Eclipse using http://cs.sensiolabs.org/
Zend Studio - This can easily be imported - https://github.com/wcomnisky/php-formatter
Atom - https://atom.io/packages/php-fmt is a good one but I prefer https://atom.io/packages/php-cs-fixer

Now though this helps set up but enforcing is still not near. For a multitude of reasons these might change, stop working completely or partially. Due to over sight or mistake or whatever reason suddenly your repo might have non PSR compliant code.

So how do we enforce, what can we do to make sure our team ALWAYS commits PSR compliant code in the repos.

GIT Pre Commit hook is our saviour here. A ready solution is https://github.com/hootsuite/pre-commit-php

Just add to your .pre-commit-config.yaml file with the following

- repo: git@github.com:hootsuite/pre-commit-php.git
 sha: 1.1.0
 hooks:
  - id: php-cs
   files: \.(php)$
   args: [--standard=PSR1 -p]
  - id: php-cs-fixer
   files: \.(php)$
   args: [--level=PSR2]

The above handles PSR 1 and PSR 2 adding few more lines can also enable Lint and Unit testing.

While setting up the IDE help the developer follow the PSRs, the Pre Commit Hook will enforce that the commits only reach the repo if the standards are being followed. With this few minutes read and install Startups, SME's corporates everyone can enforce Development Teams write Good Code (PSR 1 and 2 compliant)