Show Menu
Cheatography

Clean Code Cheat Sheet by

clean code principles, rules, design, and more

S.O.L.I.D

SRP single respon­sib­ility principle
OCP open closed principle
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­(start with final and private as default)
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­ile.ht­ml.twig
Prefix Template Fragments with an Unders­core: _user_­ava­tar.ht­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 builde­r|c­ommand pattern to construct a complex DTO

Function

Minimalize the number of arguments
has only one level of abstra­ction
avoid side effects
don't use flag(e.g. $isSom­eth­ing­Spe­cial) as function argument
avoid complex conditions
function names should say what they do
avoid using negative condit­ionals
just do one thing
use explicit function instead of generic setter

Doctrine

Use only Interface to access database in applic­ation & domain layers
Implement CQS 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

Migration

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

Tests

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
 

Comments

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
          C Reference Cheat Sheet
          Java + OOP concept Cheat Sheet

          More Cheat Sheets by vikbert

          Onion Architecture + Symfony Cheat Sheet