The PHP community is making great efforts to enforce coding standards. The purpose of this is to make interoperability of frameworks easier to maintain. It also helps developers understand and read code if it adheres to a certain set of rules. Java has already had for a long time in the form of a JCP by creating JSRs to propose language changes as well as API creation. This is a similar effort.
PSR-0 was a great success and now they have 2 newer proposals called PSR-1 and PSR-2.
PSR-0
It describes a standard that must be adhered to for defining class Autoloaders. I will briefly explain each one:- A fully-qualified namespace and class must have the following structure
\ \ ()* \ Each namespace must have a top-level namespace ("Vendor Name"). Each namespace can have as many sub-namespaces as it wishes. Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system. Each "_" character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The "_" character has no special meaning in the namespace. The fully-qualified namespace and class is suffixed with ".php" when loading from the file system. Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case.
What PSR-0 boils down to is that your PHP file locations match the namespace provided. In very similar fashion that Java package names match the directory structure.
PSR-1
Most of these are self-explanatory, I tried to add more details to the ones that are not:Files MUST use onlyandtags.Files MUST use only UTF-8 without BOM for PHP code.
A BOM (byte-order mark) is a character that indicates the byte order of a stream. The Unicode Standard does permit the BOM but does not require or recommend its use. Byte order has no meaning in UTF-8 , it serves only to identify a text stream or file as UTF-8.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.
This
also serves to keep classes with functions and constants in their
seperate files. If a file changes .ini settings, have that file just do
that and provide a clear name that this is a configuration file.Namespaces and classes MUST follow PSR-0 (read above).Class names MUST be declared inStudlyCaps.Class constants MUST be declared in all upper case with underscore separators.Method names MUST be declared incamelCase.
PSR-2
PSR-2Code MUST follow PSR-1 (read above)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 thenamespacedeclaration, and there MUST be one blank line after the block ofusedeclarations.Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body (not so critical).Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body (not so critical).Visibility MUST be declared on all properties and methods;abstractandfinalMUST be declared before the visibility;staticMUST 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.
The following is an example of what a class should look like after applying some of the principles described here, they had incosistencies in the braces in their example so I fixed them here:
Stay Tuned!
visit http://reflectivethought.net
Resources
Resources
- https://gist.github.com/1234504
- https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-1-basic.md
- https://github.com/pmjones/fig-standards/blob/psr-1-style-guide/proposed/PSR-2-advanced.md