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