PHP Dublin Meetup - Clean Code in PHP

© 2019 Magento, Inc. Page 1.1.1
Clean Code in PHP

• Paras Sood - Software Engineer at Magento
University
• Working on PHP/Magento since 2011
• Passionate about education and training in the
Technology sector
• Twitter - ParasSood29
About Me:

• What is Clean Code
• Examples
• Naming Variables, Functions, Classes, DB entities
• Comments, Exception handling –try/catch, Tests etc
• Further Reading – concepts and resources
• Questions – feel free to interrupt
Agenda

What is Clean Code?

What is Clean Code?
• Readable – easy to read and understand – avoid things like nested
ternary operators
• No ”Smart” tricks – avoid things like magic getters/setters
• Does things explicitly rather than implicitly by avoiding addition of side
effects
• Maintainable
• Easy to add functionality to
• Easy to re-factor – avoid unnecessary coupling
• Easy to test – good dependency management

Before we proceed….

Example 1 – return types, use of constants, descriptive names and more

Example 2 – magic of early returns, variable naming and avoiding mental mapping

Summary - Variables, DB tables, Columns, Functions, Class naming
• Use descriptive names – even if they are long – getWholesaleCustomerOrders vs getOrders
• Avoid duplicating context
• getOrders is enough if the context is already Whole sale customers by way of a class
etc.
• customer_account table: customer_account_id vs account_id vs id
• Be consistent with naming – get vs fetch vs load should be used consistently and not
interchangeably
• Function names should generally be verbs – fetchOrdersFromERP(), placeOrder(),
instantiateSession(); etc. vs public function erpOrders()
• Class and object names should be nouns unless you are implementing something like a
command pattern – OrderProcessor, OrderSender vs SendOrder

Example 3: Functions: Single level of abstraction, avoid passing flags to
functions

Example 4: Use object encapsulation – follow the Open/Closed principle

Some Comments on well……. Comments
• Do not add comments that state the obvious
• Good code should be self explanatory
• Needing comments to describe what the code does is a code smell –
consider re-factoring
• In Certain conditions comments are acceptable:
• Documenting a certain decision
• Warning other developers of consequences of changing something
• PHPDocs for API methods
• Comments are hard to maintain
• Unnecessary commenting obscures the useful comments

Try/Catch Blocks and Exception Handling
• Use exceptions rather than return codes – makes the calling code cleaner and
not scattered with error handling logic
• Write the try-catch-finally block first – this helps you be conscious about what
you need to do in case the called code throws an exception
• Provide context with the exception – ‘Unable to connect to the DB’ is better
than ‘Something went wrong!’. Providing more context may also help with
logging in the catch
• Don’t return null from a method – throw an exception instead, or a special case
object
• Wrap third party API calls in a local class
• Not tied to the design choices of the third party
• Better control over exceptions that are thrown to internal code
• Less dependency on the third party API, can substitute with another third
party service in future
• Easier to mock/test with internal code

Unit Tests
• Keep them clean – need to maintain them later with production code
• What makes a test clean? – Readability
• Write one assert per test
• Follow FIRST –
• F - Fast
• I - Independent
• R – Repeatable
• S – Self Validating
• T – Timely – it’s too hard later to adjust code

Further Reading
Concepts:
• DRY
• SOLID principles
• Law of Demeter
Books:
• Robert Martin’s Clean Code

Questions?

PHP Dublin Meetup - Clean Code in PHP

More Related Content

Similar to PHP Dublin Meetup - Clean Code in PHP (20)

Recently uploaded (20)

PHP Dublin Meetup - Clean Code in PHP

Editor's Notes