Let’s PHP in a better way!Coding Recommendations.

Leekas Shep/Leekas

1

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

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!

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

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

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

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..

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

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

PSR-2 : Coding Style Guide

/Leekas

10

The SOLID Agile Principles

● Single Responsibility Principle● Open/Closed Principle● Liskov Substitution Principle● Interface Segregation Principle● Dependency Inversion Principle

/Leekas

11

Single Responsibility Principle

/Leekas

12

A class should have only one reason to change.

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!

Liskov Substitution Principle

/Leekas

14

Child classes should never break the parent class' type definitions.

Coz, you’ll never know!!

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.

Dependency Inversion Principle

/Leekas

161. 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.

Design Patterns - Hand-Picked!

●Strategy Pattern●Facade Pattern●Decorator Pattern

/Leekas

17

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.

Strategy Pattern

/Leekas

19

Facade Pattern

/Leekas

20

Facade Pattern

/Leekas

21

Decorator Pattern

/Leekas

22

Decorator Pattern

/Leekas

23

YES!!

Any questions?

Hook ‘em up!

/Leekas

24

Thank You!!“Love your code.. Embrace your craft.. Do better..”

Leekas Shep/Leekas

25