Downloaded 21 times
![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](https://image.slidesharecdn.com/letsphpinabetterway-161025062922/75/Let-s-PHP-in-a-better-way-Coding-Recommendations-8-2048.jpg)
![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](https://image.slidesharecdn.com/letsphpinabetterway-161025062922/75/Let-s-PHP-in-a-better-way-Coding-Recommendations-9-2048.jpg)
Let's PHP in a better way! - Coding Recommendations.
- 1. Let’s PHP ina better way! Coding Recommendations. Leekas Shep /Leekas 1
- 2. Sneak Peek ● CodingStandards ● Coding Principles ● Design Patterns We’ll be walking through.. .. and we’ll keep it short and sane /Leekas 2 Hand- Picked
- 3. Hai There.. ● PHPprogrammer ● 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 : BasicCoding 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 : CodingStyle 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 : CodingStyle Guide /Leekas 10
- 11. The SOLID AgilePrinciples ● Single Responsibility Principle ● Open/Closed Principle ● Liskov Substitution Principle ● Interface Segregation Principle ● Dependency Inversion Principle /Leekas 11
- 12. Single Responsibility Principle /Leekas 12 Aclass 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 Childclasses should never break the parent class' type definitions. Coz, you’ll never know!!
- 15. Interface Segregation Principle /Leekas 15 Theinterface-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 ● Identifyan 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.
- 20.
- 21.
- 22.
- 23.
- 24. YES!! Any questions? Hook ‘emup! /Leekas 24
- 25. Thank You!! “Love yourcode.. Embrace your craft.. Do better..” Leekas Shep /Leekas 25