Please enable JavaScript.
Coggle requires JavaScript to display documents.
Clean Code by Robert C. Martin (Objects/Data Structurus (OO code make it…
Clean Code by Robert C. Martin
Naming
Variables
use (source, destination) instead of (a1, a2)
don't use abbreviations
use pronounceable names
avoid disinformation - never name thingsList if it is not list
use searchable names
Classes
use noun or noun phrase Customer, AddressParser
avoid Manager, Processor, Data, Info in the name of class
Methods
use verb or verb phrase like postPayment, deletePage
Pick one word per concept, don't pun
Functions
keep them small - not more than 20 lines
should do one thing, should do it well, should do it only
one level of abstraction per function
use Abstract Factory to avoid repeating of switch statement,
create once and call methods polymorphically
Arguments
Monadic - 1 argument
transform input type to new one: open("file_path")
file_path String to File object
asking questions:
fileExists("file_path")
event (not output):
void passwordAttemptFailedNtimes(int attempts)
avoid all other forms of Monadic functions:
modifying passed argument and returning - return new value instead
Dyadic - 2 arguments
try to convert to monadic
Triads - 3 arguments
Polyadic - more than 3 arguments
Avoid Flag Arguments:
always function will be doing at least two actions
split to two function instead
Objects/Data Structurus
OO code make it easy to add new classes without changing existing functions, Procedural code(Data Structures) on the other hand makes it easy to add new functions without changing the existing data structures
Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change
Things that are hard for OO are easy for procedures and visa versa
The law of Demeter:
The method should not invoke methods on objects that are returned by any of the allowed functions.
Talk to friends, not to strangers.
Objects expose behavior and hide data. Easy to add new kinds of objects. Hard to add new behavior
Data structures expose data and have no functions. Easy to add new functions, hard to add new data structures
Don't use hybrids of Procedural and OO like
DTO(data transfer object) class with getters and setters
Chose OO or Procedural without prejudice
Error Handling
Special Case Pattern
Return specific object implementation instead of adding specific business logic at exception handling part
Don't return null
Return Special object (empty list for instance)
If you are using third-party null-returning API wrap it to throw an exception or return special case object
Never pass Null as argument
Tests
F.I.R.S.T.
F - Fast
I - Independent
R - Repeatable
S - Self-Validating
T - Timely
4 Rules of Simple Design
Runs all tests
Contains no duplication
Express the intent of the programmer
Minimizes the number of classes and methods
General(Other)
G23: Prefer Polymorphism to If/Else or Switch/Case
ONE SWITCH rule
There may be no more than one switch statement for a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of other such switch statements in the rest of the system
G31: Hidden Temporal Couplings
G35: Keep Configurable Data at High Levels
G36: Avoid Transitive Navigation