7 Golden Rules for simple, clean and maintainable code

Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc

Transcript

1. 7 GOLDEN RULES OF SCRUMT CODE Simple, Clean, Readable, Understanable, Maintainable (Testable) Code Slides by , presented by Sumit Chhetri. Geshan Manandhar
2. WHY WRITE CLEAN CODE
3. Code for humans not machines Think that the next person who reads your code is a chainsaw maniac If you don't write clean code, you know your fate.
4. Rule 1: Follow a consistent coding standard If you are doing PHP follow Other languages like Java, Python, Javascript also have coding standards Use a linter or CS fixer to follow the standard. Integrate build tools in Sublime or use default PHPStrom code refactor, to automate this Makes it easy for everyone - including yourself - in the team, to read the code PSR-2
5. Rule 2: Name things properly, long variable and function/method names are allowed Stick to one convention. ($someVariable or $SomeVariable or $some_variable) Don't use abbreviations, may not be understandable to the person, who reads your code Naming is difficult, do it well. Name classes, variables and methods that make sense Do not be redundant. Example
6. Rule 3: Be expressive, write code as you speak and be optimally verbose Focus on API rather than patterns. First, write down the API for perfect scenario, observe how it feels, then jump to coding and make it work. Tell, don't ask. Example
7. Rule 4: Max indent per method should be 2, in case of exceptions 3 Avoid the use of else. Extract the logic to other readable method. Return early Throw exception Example
8. 6 levels of indentation (in our public code) source p u b l i c f u n c t i o n s e t t i n g s A c t i o n ( ) { / / 0 i f ( $ _ P O S T ) { / / 1 t r y { / / 2 . . . } e l s e { . . . / / 3 i f ( $ r e p o r t i n g O r g N e w ! = $ r e p o r t i n g O r g O l d ) { / / 4 i f ( $ s a v e = = " o k " ) { . . . / / 5 i f ( $ a c t i v i t y P u b l i s h ) { / / 6
9. Rule 5: Avoid creating and long methods god object One class should do one thing not everything like S t a t u s C h a n g e r or S t a t u s M a n a g e r not S t a t u s G o d Avoid using a n d in method names like v a l i d a t e A n d S a v e , one method needs to do one thing and one thing well Keep methods small, a 50 line method is a problem Keep classes small, a 1000 line class is a pain Keep the instance variables to as low as 6 or 7.
10. Rule 6: Keep the method in one place, inject the class and call it, DRY In MVC keep controllers slim, business logic belongs to services or repositories, check for controller 5-10-20 If you access property of a property a->b->c->d() there is something wrong, you can use a wrapper or proxy function. Use language constructs like interfaces, traits to make code more expressive and reusable If you find yourself copying the same code several times, extract that code into its own method. Refactor your code, every once in a while. symfony best practice Example
11. Rule 7: Avoid in-line comments (comment with code), put comments in the method doc Comment is a code smell (anti pattern), like If you need to write comments to explain your code, means you need to put it in a new method. here Example p u b l i c f u n c t i o n a d d A c t i v i t y ( $ d a t a , $ d e f a u l t ) { $ t h i s - > d e f a u l t s = $ d e f a u l t ; $ i d e n t i t y = Z e n d _ A u t h : : g e t I n s t a n c e ( ) - > g e t I d e n t i t y ( ) ; / / v a r _ d u m p ( $ d a t a ) ; e x i t ; $ m o d e l = $ t h i s - > m o d e l ; $ m o d e l A c t i v i t y = n e w M o d e l _ A c t i v i t y ( ) ; $ a c t i v i t i e s I d = $ m o d e l - > g e t I d B y F i e l d ( ' i a t i _ a c t i v i t i e s ' , ' a c c o u n t _ i d ' , $ i d e n t / / C r e a t e a c t i v i t y a n d i t s d e f a u l t s $ i a t i I d e n t i f i e r [ ' a c t i v i t y _ i d e n t i f i e r ' ] = $ d a t a [ ' i d e n t i f i e r ' ] ;
12. Other considerations Avoid working with just arrays for large data sets, use class and type hint Rather than starting to write something on your own spend 5 minutes to read the framework/library documentation to know if its already provided Extract out methods and rename variables as necessary Read about cyclomatic complexity and N-Path complexity, here
13. Recap 1 Rule 1: Follow a consistent coding standard Rule 2: Name things properly, long variable and function names are allowed Rule 3: Be expressive, write code as you speak and be optimally verbose Rule 4: Max indent per method should be 2, in case of exceptions 3
14. Recap 2 Rule 5: Avoid creating and long methods Rule 6: Keep the method in one place, inject the class and call it, Rule 7: Avoid in-line comments (comment with code), put comments in the method doc Dont forget the consideration and reading god object DRY PS: you can print the recap slides and mug them up.
15. References Most code examples are taken from YIPL open source code on Github. Rules for simpler code - laracast Maintainable Code Readable Code Object Calisthenics Your code sucks - let fix it
16. Thanks Hope we can step by step minimize code complexity and write SCRUMT code. Remember, simple, understandable, readable and eventually maintainable code is greater than any pattern ever invented (be practical).