2. PSR-2's purpose is to have a single
style guide for PHP code that
results in uniformly formatted
shared code.
3. ● PSR-2 is a coding style agreed upon by many
PHP framework developers
● It’s an extension of the original PSR-1,
which basically has 3 main conventions.
● The benefit of PSR-2 is not in the rules
themselves, but in the sharing of those
rules.
4. 3 Main Conventions of PSR-1
● Classes are upper CamelCase.
● Methods are lower camelCase.
● Constants are written in caps like
VERSION_NUMBER.
5. Some other rules of PSR-1
● Files MUST use only <?php and <?= tags.
● Files MUST use only UTF-8 without BOM for
PHP code.
● Class names MUST be declared in StudlyCaps
(text notation in which the capitalization of letters
varies by some pattern, or arbitrarily, usually also
omitting spaces between words and often omitting some
letters).
etc...
6. PSR-2 expands PSR-1 by using these
standards:
● Indents are 4 spaces instead of tabs.
● All PHP files MUST end with a single blank line.
● The closing ?> tag MUST be omitted from files
containing only PHP.
● Keep line lengths at 80 characters. Soft limit of
120 characters.
● Use one blank line after a namespace declaration.
● Use a blank line after a group of declarations.
7. ● There MUST NOT be trailing whitespace at the end of
non-blank lines.
● The `extends` and `implements` keywords MUST be
declared on the same line as the class name.
● Visibility MUST be declared on all methods.
● In the argument list, there MUST NOT be a space before
each comma, and there MUST be one space after each
comma.
8. ● Opening braces for classes MUST go on the next line.
Closing brace must be on its own line.
● Opening braces for methods must go on the next line,
and a separate line for the closing brace.
● Closures must have a space after the function keyword.
● Never use the var keyword, this is used with
JavaScript and would cause some confusion.
● Control structures, like IF, WHICH, FOR, and FOREACH
must have one space before the condition parenthesis.
● The case keywords should be indented from the switch
keyword.
● Keywords, like true, false, and null should be in
lowercase.
19. What PHPMD does?
It takes a given PHP source code
base and look for several potential
problems within that source.
20. ● PHPMD works through Rules – specific sets of
instructions on what to look for in source code
● There’s a wide variety of prepared rules and
users can write their own
● PHPMD can be installed globally via composer by
running
composer global require 'phpmd/phpmd=*'
21. Potential Problems within
the Source:
● Possible bugs
● Suboptimal code
● Overcomplicated expressions
● Unused parameters, methods, properties
etc.
22. Some examples of rules:
● Clean Code Rules: enforce a clean code base.
● Naming Rules: about names - too long, too short,
and so forth
● Unused Code Rules: finds unused code.
● ElseExpression: An if expression with an else
branch is never necessary. You can rewrite the
conditions in a way that the else is not necessary
and the code becomes simpler to read. To achieve
this use early return statements.
23. ● ExcessiveMethodLength: Try to reduce the method
size by creating helper methods and removing
any copy/pasted code.
● ExcessiveClassLength: Try to break it down, and
reduce the size to something manageable.
● ExcessiveParameterList: Long parameter lists
can indicate that a new object should be
created to wrap the numerous parameters.
● ExcessivePublicCount: A large number of public
methods and attributes declared in a class can
indicate the class may need to be broken up.
24. ● CamelCaseClassName: It is considered best practice
to use the CamelCase notation to name classes.
● CamelCasePropertyName: use the camelCase notation
to name attributes.
● CamelCaseMethodName: use the camelCase notation to
name methods.
● CamelCaseParameterName: use the camelCase notation
to name parameters.
● CamelCaseVariableName: use the camelCase notation
to name variables.
25. ● NumberOfChildren: A class with an excessive number of
children is an indicator for an unbalanced class
hierarchy. You should consider to refactor this class
hierarchy.
● DepthOfInheritance: A class with many parents is an
indicator for an unbalanced and wrong class hierarchy.
● ShortVariable: Detects when a field, local, or
parameter has a very short name.
● LongVariable: Detects when a field, formal or local
variable is declared with a long name.
● ShortMethodName: Detects when very short method names
are used.
● ConstantNamingConventions: Class/Interface constant
names should always be defined in uppercase.
