php-coding-standards.markdown

@@ -5,17 +5,22 @@
 # PHP Coding Standards
 
 
+
 ## Shameless Copy of [Symfony Coding Standards](http://symfony.com/doc/master/contributing/code/standards.html)
 
+
 >  __These standards are borrowed from the Symfony Standards. They are edited by Digitec when appropriate.__
 >  __All of the examples below have been edited to reflect Digitec changes.__
 
 KD7 will follow the standards defined in the PSR-0, PSR-1 and PSR-2 documents.
 
+
 Remember that the main advantage of standards is that every piece of code looks and feels familiar, it's not about this or that being more readable.
 
 Since a picture - or some code - is worth a thousand words, here's a short example containing most features described below:
 
+
+
 ```php
 <?php
 
@@ -52,7 +57,7 @@ class FooBar {
      * @return string|null Transformed input
      */
     private function transformText($dummy, array $options = array()) {
-        $merged_options = array_merge(
+        $mergedOptions = array_merge(
             $options,
             array(
                 'some_default' => 'values',
@@ -64,7 +69,7 @@ class FooBar {
             return;
         }
         if ('string' === $dummy) {
-            if ('values' === $merged_options['some_default']) {
+            if ('values' === $mergedOptions['some_default']) {
                 $dummy = substr($dummy, 0, 5);
             } else {
                 $dummy = ucwords($dummy);
@@ -96,24 +101,36 @@ class FooBar {
 
 ### Naming Conventions
 
-* Use camelCase, not underscores, for function and method names;
-* Use underscores for variables, arguments, array keys, and object properties;
+* Use camelCase, not underscores, for variable, function and method names, arguments;
+
+* Use underscores for option names and parameter names;
+
 * Use namespaces for all classes;
+
 * Prefix abstract classes with Abstract;
+
 * Suffix interfaces with Interface;
+
 * Suffix traits with Trait;
+
 * Suffix exceptions with Exception;
+
 * Use alphanumeric characters and underscores for file names;
+
 * Don't forget to look at the more verbose Conventions document for more subjective naming considerations.
 
 ### Documentation
 
 * Add PHPDoc blocks for all classes, methods, and functions;
+
 * Omit the @return tag if the method does not return anything;
+
 * The @package and @subpackage annotations are not used.
 
+
 ---
 
+
 ## [PSR-0](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md)
 
 Autoloading Standard
@@ -190,6 +207,7 @@ load your classes if you follow the autoloader interoperability
 standards proposed above. It is the current recommended way to load PHP
 5.3 classes that follow these standards.
 
+
 - http://gist.github.com/221634
 
 ---
@@ -222,12 +240,17 @@ interpreted as described in [RFC 2119].
 > Digitec code MUST use only the `<?php` tags.
 
 - Files MUST use only UTF-8 without BOM for PHP code.
+
 - 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.
+
 - 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`.
 
 
@@ -403,11 +426,15 @@ interpreted as described in [RFC 2119].
 -----------
 
 - 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~~ __same__ line, and closing braces MUST
   go on the next line after the body.
 
@@ -421,10 +448,13 @@ interpreted as described in [RFC 2119].
 - 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.
 
@@ -495,7 +525,7 @@ Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.
 
 > N.b.: Using only spaces, and not mixing spaces with tabs, helps to avoid
 > problems with diffs, patches, history, and annotations. The use of spaces
-> also makes it easy to insert fine-grained sub-indentation for inter-line
+> also makes it easy to insert fine-grained sub-indentation for inter-line 
 > alignment.
 
 ### 2.5. Keywords and True/False/Null
@@ -631,7 +661,7 @@ class ClassName {
         // method body
     }
 }
-```
+```    
 
 ### 4.4. Method Arguments
 
@@ -669,7 +699,7 @@ class ClassName
     public function aVeryLongMethodName(
         ClassTypeHint $arg1,
         &$arg2,
-        array $arg3 = []
+        array $arg3 = [] 
     ) {
         // method body
     }
@@ -830,7 +860,7 @@ for ($i = 0; $i < 10; $i++) {
 ```
 
 ### 5.5. `foreach`
-
+    
 A `foreach` statement looks like the following. Note the placement of
 parentheses, spaces, and braces.
 
@@ -971,16 +1001,23 @@ There are many elements of style and practice intentionally omitted by this
 guide. These include but are not limited to:
 
 - Declaration of global variables and global constants
+
 - Declaration of functions
+
 - Operators and assignment
+
 - Inter-line alignment
+
 - Comments and documentation blocks
+
 - Class name prefixes and suffixes
+
 - Best practices
 
 Future recommendations MAY revise and extend this guide to address those or
 other elements of style and practice.
 
+
 ---
 
 ###### References