My coding standards [en]

Useful links

• the PHP manual
• the PHPUnit manual
• the Composer and Packagist websites
• the X-Debug documentation

Coding styles

Base standards

I MUST try to follow the coding standards and naming rules most commonly in use:

• the PEAR coding standards
• the PHP Framework Interoperability Group standards.

My coding rules

• script files MUST all be encoded with LF line ending (UNIX “linefeed”) in classic UTF-8 character set with NO BOM ;
• lines in a script MUST never be more than 120 characters length and SHOULD NOT be more than 80 ;
• indent is made with 4 spaces (no tab, never) ; this is true for (quite) all languages ;
• PHP language’s keywords MUST be written all lower case
• methods are written in camelCase: words are identified with a first capital letter and the rest in lower case ; the very first letter is NOT upper case ; a leading underscore CAN identify a special method (not only for access reason), keeping in mind that double-underscores are reserved for internal magic PHP methods ;
• properties are written in snake_case: all lower case with words separated by underscores ; an optional leading underscore COULD identify a special access for the property (a protected or private class’ property for instance) ;
• constants are written all upper case with underscore delimiter ;
• the extends and implements lists COULD be written each on a new line, with indentation:

  class MyClass
      extends MyOhterClass
      implements MyInterface, MyOtherInterface
  {
  }
  

  ; this rule is NOT compliant with standards but seems to me really more efficient in practice, and compliant with the idea of lines length limit ;

• interfaces are suffixed with Interface:

  interface MyObjectInterface
  {
  }
  

• traits are suffixed with Trait:

  trait MyObjectTrait
  {
  }
  

• abstarct classes are suffixed with Abstract¹:

  abstract class MyObjectAbstract
  {
  }
  

• exception classes are suffixed with Exception and extend another Exception class:

  class MyObjectException extends \Exception
  {
  }
  

• exceptions SHOULD always have a significant message with current properties or variables which caused the error ; such message SHOULD be concatenated using the sprintf() internal function and MUST NEVER end with a punctuation:

  throw new \ErrorException(
      sprintf('%s::$proxy_class is expected to be a valid class name, "%s" given',
          get_called_class(), $this::$proxy_class)
  );
  

• errors SHOULD follow the same rules:

  user_error(
      sprintf('Call to undefined or inaccessible method %s::%s()', get_called_class(), $name),
      E_USER_ERROR
  );
  

PHP autoloader

As I try to always use Composer for my packages, I follow the PSR-4-autoloader rules to name and store my classes.

Following these rules, I made a complete and portable fork of the original Jonathan Wage‘s SplClassLoader with a test of file existence to avoid the require error if the file does not exist. My version allows to use a classic

if (class_exists( ... ))

which does not break the original internal function purpose and usage (it may return false if the class does not exist). You can find my fork at https://gist.github.com/piwi/0e7f1560365162134725.

Common rules

@api @deprecated

Classes naming

Just like the PHP “stdClass”, an object which defined a “standard” pattern or a basic minimalist object SHOULD be named prefixed by “Std”.

My “magic” methods

Just like PHP does, some commonly used methods can be identified and ruled for code homogeneity. We can first identify some “classic” access and test method names like:

get()
set()
isset() or has()
unset()

As these methods will often be defined to access some class properties, we can first try to define an automation system for these accessors using the magic PHP methods __set(), __get(), __isset() and __unset().

To be continued …