2. DRY
DONâT REPEAT YOURSELF
I will not repeat myself
I will not repeat myself
I will not repeat myself
I will not repeat myself
I will not repeat myself
I will not repeat myself
REPETITION IS THE ROOT OF ALL SOFTWARE EVIL
As soon as you start repeating yourself (e.g. a long expression, a
series of statements, same concept) create a new abstraction.
@ardentlearner
1
3. ABSTRACT
Each significant piece of functionality in a program should be
implemented in just one place in the source code.
Main Problem
1st layer abstraction
2nd layer abstraction
3rd layer abstraction
@ardentlearner
2
5. YAGNI
Avoid Creating a YAGNI
(You arenât going to need it)
You should try not to add
functionality until you need it.
Pain
âHey,
we could âŠâ
YAGNI
The simplest
thing that could
possibly work
No Pain
@ardentlearner
4
6. SIMPLE
ITâS THE
THINGS
THAT MAKE A
Do the simplest thing that could possibly work.
A good question to ask oneâs self when programming is,
âWhat is the simplest thing that could possibly work?â
This helps keep us on the path towards simplicity in the design.
@ardentlearner
5
7. DONâT MAKE ME THINK
The code should be easily read and understood with a
minimum of effort required.
If code requires too much thinking from an observer to
understand, then it can probably stand to be simplified.
@ardentlearner
6
8. OPEN / CLOSED
OPEN
MODIFICATION
FOR
EXTENSION
CLOSED
Software entities (classes, modules, functions, etc.) should be
open for extension,
but
closed for modification.
In other words, do not write classes that people can modify.
Write classes that people can extend.
@ardentlearner
7
9. MAINTAINABLE
Write Code for the Maintainer
Almost any code that is worth
writing is worth maintaining in
the future.
WRITE YOUR
AS IF THE PERSON
MAINTAINING IT
IS A
HOMICIDAL
MANIAC
WHO KNOWS
WHERE YOU LIVE
@ardentlearner
8
10. LEAST ASTONISHMENT
Code should surprise the reader as little as possible.
This means following standard coding conventions and
the code should do what the comments and name suggest and any
potentially surprising side effects should be avoided as much as
possible.
@ardentlearner
9
13. MAXIMIZE COHESION
âThings that belong together should be kept togetherâ
Makes code easier to understand, debug and test.
@ardentlearner
12
14. THE LAW OF DEMETER
Talk only to your closest friends
THE LAW OF DEMETER
is also known as
Principle of Least Knowledge
@ardentlearner
13
15. AVOID PREMATURE OPTIMIZATION
Donât even think about optimization unless your code is working
but slower than you want. Only then should you start thinking
about optimizing and only with the aid of empirical data.
"We should forget about small efficiencies, say about 97% of the time:
Premature Optimization is the root of all evil" - Donald Knuth.
@ardentlearner
14