Skip to content

GitLab

php coding standards · Changes

Page history
mmclin: update naming conventions authored by Mike McLin's avatar Mike McLin
Show whitespace changes
Inline Side-by-side
php-coding-standards.markdown
View page @ e43b00c1
......@@ -5,22 +5,17 @@
# 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
......@@ -41,13 +36,13 @@ namespace Acme;
class FooBar {
const SOME_CONST = 42;
private $fooBar;
private $foo_bar;
/**
* @param string $dummy Some argument description
*/
public function __construct($dummy) {
$this->fooBar = $this->transformText($dummy);
$this->foo_bar = $this->transformText($dummy);
}
/**
......@@ -88,58 +83,37 @@ class FooBar {
### Structure
* Add a single space after each comma delimiter;
* Add a single space around operators (==, &&, ...);
* Add a comma after each array item in a multi-line array, even after the last one;
* Add a blank line before return statements, unless the return is alone inside a statement-group (like an if statement);
* Use braces to indicate control structure body regardless of the number of statements it contains;
* Define one class per file - this does not apply to private helper classes that are not intended to be instantiated from the outside and thus are not concerned by the PSR-0 standard;
* Declare class properties before methods;
* Declare public methods first, then protected ones and finally private ones;
* Use parentheses when instantiating classes regardless of the number of arguments the constructor has;
* Exception message strings should be concatenated using sprintf.
### Naming Conventions
* Use camelCase, not underscores, for variable, function and method names, arguments;
* Use underscores for option names and parameter names;
* Use camelCase, not underscores, for function and method names;
* Use underscores for variables, arguments, array keys, and object properties;
* 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
......@@ -216,7 +190,6 @@ 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
---
......@@ -249,17 +222,12 @@ 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`.
......@@ -435,15 +403,11 @@ 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.
......@@ -457,13 +421,10 @@ 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.
......@@ -1010,23 +971,16 @@ 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
......