This document provides recommendations for PHP coding standards and principles. It discusses the PEAR, Zend, and PSR coding standards, as well as the SOLID principles of single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. Specific design patterns like strategy, facade, and decorator are also covered at a high level. The overall message is about continuously improving coding skills through learning and applying best practices.

1. Let’s PHP in a better way!
Coding Recommendations.
Leekas Shep
/Leekas
1

2. Sneak Peek
● Coding Standards
● Coding Principles
● Design Patterns
We’ll be walking through..
.. and we’ll keep it short and sane
/Leekas
2
Hand-
Picked

3. Hai There..
● PHP programmer
● Working in collaboration
● Values quality codebase
● Develops scalable applications
● Most importantly, a love for coding
You can benefit the most out of this session,
if you are..
/Leekas
3
No one never ever gonna
touch my code..
Scaling and maintenance
is not even in my wildest
dreams..
And I’ve no love for
coding.. Yes, I hate my
life...
Then, you are in the
wrong place mate! Run!

4. Coding Standards - Hand-Picked!
● PEAR Coding Standards
● Zend Coding Standards
● PSR Coding Standards
Some of the well known and widely accepted coding standards..
/Leekas
4

5. PEAR Coding Standards
● One of the first proposed and
widely accepted standards
● Adheres to most of the old-
school practices
(PHP Extension and Application Repository)
/Leekas
5

6. Zend Coding Standards
● Follows the PEAR standards for
the most part
● No closing tag ( ?> )
● Abstract classes and Interfaces
should have postfixes in the
name - Optional in latest
standards.
/Leekas
6

7. PSR Coding Standards
● Published by the PHP Framework Interop Group (PHP-FIG)
● Similar to Java Specification Request for Java
(PHP Standard Recommendation)
/Leekas
7
● PSR-1 : Basic Coding Standard
● PSR-2 : Coding Style Guide
● PSR-4 : Autoloader Specifications
PSR-4 Basically deals with
namespaces and file-
directory structure
conventions..

8. PSR-1 : Basic Coding Standard
● Files MUST use only <?php and <?= 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.
/Leekas
8

9. PSR-2 : Coding Style Guide
● 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 line, and closing braces MUST go on
the next line after the body.
● Opening braces for methods MUST go on the next line, and closing braces MUST go on
the next line after the body.
● 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.
/Leekas
9

10. PSR-2 : Coding Style Guide
/Leekas
10

11. The SOLID Agile Principles
● Single Responsibility Principle
● Open/Closed Principle
● Liskov Substitution Principle
● Interface Segregation Principle
● Dependency Inversion Principle
/Leekas
11

12. Single Responsibility Principle
/Leekas
12
A class should have only
one reason to change.

13. Open/Closed Principle
/Leekas
13
Software entities
(classes, modules,
functions, etc.) should
be open for extension,
but closed for
modification.
Hmm.. Those
dependency
injection
trickies.. Luv it!
Those were the
days!

14. Liskov Substitution Principle
/Leekas
14
Child classes should
never break the parent
class' type definitions.
Coz,
you’ll
never
know!!

15. Interface Segregation Principle
/Leekas
15
The interface-segregation
principle (ISP) states that no
client should be forced to
depend on methods it does
not use.

16. Dependency Inversion Principle
/Leekas
16
1. High-level modules should
not depend on low-level
modules. Both should depend
on abstractions.
2. Abstractions should not
depend upon details. Details
should depend upon
abstractions.
The Dependency Inversion Principle is one
that leads or helps us respect all the other
principles.

17. Design Patterns - Hand-Picked!
● Strategy Pattern
● Facade Pattern
● Decorator Pattern
/Leekas
17

18. Strategy Pattern
/Leekas
18
● Identify an algorithm (i.e. a
behavior) that the client would
prefer to access through a "flex
point".
● Specify the signature for that
algorithm in an interface.
● Bury the alternative
implementation details in
derived classes.
● Clients of the algorithm couple
themselves to the interface.

19. Strategy Pattern
/Leekas
19

20. Facade Pattern
/Leekas
20

21. Facade Pattern
/Leekas
21

22. Decorator Pattern
/Leekas
22

23. Decorator Pattern
/Leekas
23

24. YES!!
Any questions?
Hook ‘em up!
/Leekas
24

25. Thank You!!
“Love your code.. Embrace your craft.. Do better..”
Leekas Shep
/Leekas
25