Show Menu

Clean Code Cheat Sheet by

clean code principles, rules, design, and more


SRP single respon­sib­ility principe
OCP open closed principe
LSP Derived class should be substi­tutable for the base class.
ISP Interface Segreg­ation Principle
DIP Dependeny Inversion Principle

Sandi Metz's Rules

100 Classes can be no longer than 100 lines of code
5 Methods can be no longer than 5 lines of code
4 Method should have no more than 4 parameters
only 1 Controller should instan­tiate only 1 object
You should break the rules only if you have a good reason or your pair lets you.

Basic Rules

meaningful name for class, method, variable and constant
avoid using suffix for service name
remove the unused method and variable
remove the unnece­ssary variable and constant
prefer to use DateTi­meI­mmu­table for handling date
return value directly and earlier, if possible
short method, and just do one thing
set the lowest visibility to class, constant, variable, method
docblock must bring additional inform­ation
declare always the return value for method
DRY: do NOT repeat yoursefl
self-d­ocu­menting code

Symfony Specific

Use php-cs­-fixer to check the coding standard
avoid to use @template annota­­tion, prefer to use $this-­­>r­ender
prefer to use $this-­­>r­e­n­de­­r('­­@A­p­p­Bu­­ndl­­e/­i­n­de­­x.h­­tm­l­,­tw­­ig');
define the Permission via @IsGra­­nt­ed(), @Secur­­it­y­(­"­is­­_gr­­an­t­e­d(­­)")
Create a bundle for reused code, only if it is resued as a stand-­alone piece of software
Use Attributes or Annota­tions to Configure Routing, Caching and Security
Use ParamC­onv­erters If They Are Convenient
Use Snake Case for Template Names and Variables: user_p­rof­­ml.twig
Prefix Template Fragments with an Unders­core: _user_­ava­­ml.twig
Use a Single Action to Render and Process the Form, i.e. GET, POST for the same form
Use Voters to Implement Fine-g­rained Security Restri­ctions
Hardcode URLs in a Functional Test

DTO Object

validate the property with constraint annotation
always final class definition
Contains no business logic
Each client has always individual DTO
Avoid NULL values
Use builder pattern to construct a complex DTO


Minimalize the number of arguments
has only one level of abstra­ction
avoid side effects
don't use flag as function argument
avoid complex conditions
function names should say what they do
avoid using negative condit­ionals
just do one things
use explicit function instead of generic setter


Use only Interface to access database in applic­ation & domain layers
Implement CQRS in complex domain
Read operation via Repository
Write operation via Entity­Manager
Remove default value from doctrine annotation in Entity (Example: default values like type="s­­tr­i­n­g", length­­=255, nullab­­le­=­f­alse)
define public setter­/getter if really necessary


Remove the auto-g­ene­rated comments
Do not handle invalid platform, if MySQL is assumed due to full control of enviro­nment


Entity, ValueO­bject, DTO, DAO will not be mocked
Use Alice & faker for complex object
validation should not be mocked, prefer to use Valida­tio­nBu­ilder


Infras­tru­cture consists of validator, EventL­ist­ener, DBAL EnumType
Domain consists of essential operations in business flows




No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          FREQUENTLY USED DX CODES Cheat Sheet
          Java + OOP concept Cheat Sheet
          C Reference Cheat Sheet

          More Cheat Sheets by vikbert

          Onion Architecture + Symfony Cheat Sheet