Download - The principles of good programming
PRINCIPLES
OF
GOOD
PROGRAMMINGPresentation By
Angelin
@ardentlearner
As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction.
DRY
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 myselfREPETITION IS THE ROOT OF ALL SOFTWARE EVIL
DON’T REPEAT YOURSELF
@ardentlearner 1
Each significant piece of functionality in a program should be implemented in just one place in the source code.
ABSTRACT
Main Problem
1st layer abstraction
2nd layer abstraction
3rd layer abstraction
@ardentlearner 2
KISS
Simplicity (and avoiding complexity) should always be a key goal.
Simple code takes less time to write, has fewer bugs and is easier to modify.
@ardentlearner 3
Always remember to…
K I S SKEEP IT SIMPLE STUPID
YAGNI
Avoid Creating a YAGNI (You aren’t going to need it)
You should try not to add functionality until you need it.
@ardentlearner 4
YAGNI“Hey,
we could …”
The simplest thing that could possibly work
No Pain
Pain
SIMPLE
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
IT’S THE
THINGS
THAT MAKE A
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.
DON’T MAKE ME THINK
@ardentlearner 6
OPEN / 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
FOR EXTENSION
MODIFICATION
OPEN
CLOSED
MAINTAINABLEWrite Code for the Maintainer
Almost any code that is worth writing is worth maintaining in
the future.
@ardentlearner 8
WRITE YOUR
AS IF THE PERSON
MAINTAINING IT
IS A
HOMICIDAL MANIAC
WHO KNOWS
WHERE YOU LIVE
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
SINGLE RESPONSIBILITY
A component of code (e.g. class or function) should perform a single well defined task.
@ardentlearner 10
MINIMIZE COUPLING
@ardentlearner 11
“All modules should be independent as far as possible”
Improves maintainability
MAXIMIZE COHESION
@ardentlearner 12
“Things that belong together should be kept together”
Makes code easier to understand, debug and test.
THE LAW OF DEMETERis also known as
Principle of Least Knowledge
THE LAW OF DEMETER
Talk only to your closest friends
@ardentlearner 13
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
REUSE CODE
Reusing code improves code reliability
and decreases development time.
@ardentlearner 15
SEPARATION OF CONCERNS
Different areas of functionality should be managed by distinct and minimally overlapping modules of code.
@ardentlearner 16
EMBRACE CHANGE
@ardentlearner 17
HAPPY
PROGRAMMING !
@ardentlearner