The Principles of Good Programming

1. PRINCIPLES
OF
GOOD
PROGRAMMING
Presentation By
Angelin
@ardentlearner

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

4. KISS
Always remember to…
KISS
KEEP
IT
SIMPLE
STUPID
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

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

11. SINGLE RESPONSIBILITY
A component of code (e.g. class or function) should perform a
single well defined task.
@ardentlearner
10

12. MINIMIZE COUPLING
“All modules should be independent as far as possible”
Improves maintainability
@ardentlearner
11

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

16. REUSE CODE
Reusing code
improves code reliability
and
decreases development time.
@ardentlearner
15

17. SEPARATION OF CONCERNS
Different areas of functionality should be managed by
distinct and minimally overlapping modules of code.
@ardentlearner
16

18. EMBRACE CHANGE
@ardentlearner
17

19. HAPPY
PROGRAMMING !
@ardentlearner