Growing list of code, design and development related rules of thumb.

This repo is what gave me the idea to maintain the following rules of thumb.
You’ll find much better and deeper explanations there!

Fast Feedback

Both small (TDD) and large (CD) scale.

One step at a time

Refactoring a Big Ball of Mud?
Start small, even if small means apparently irrelevant, peripheral changes (variable names, directory structure, etc.).

Complexity

Complexity is sometimes necessary, but often accidental.
Avoid the latter.

Divide and conquer

Split up complexity and complex issues as much as possible.

Decide as late as possible

Think of the moment you face a decision as a crossroads.
The more information you have, the likelier the chance of choosing the ‘right’ path.

Respect the Legacy

We know at least two things about all Legacy code:

• It works.
• It’s profitable.

Respect Legacy code and the people who wrote it.

Doctrine of the Mean

Business needs to go fast.
Devs would rather take their time and ensure quality standards.
Find that Golden Mean.

Start anew

Don’t build the project of tomorrow with the crap from yesterday.

Listen to your gut feeling

Don’t dismiss it with a ‘meh, it works’. If you feel something could be better, make it better.

Be water my friend

Flexible with other peoples code.
Strict with yours.

Code

Readable

Code for other people, not for the CPU.

Naming is not relevant

It’s extremely important.

Simplistic naming

Complex naming schemes might indicate inadequate modelling.

Expl!c!t language

When in doubt be explicit.

Boring, repetitive, predictable

No surprises, no ‘WTF’.

Write code like a manual

Show what it does and how to use it.
Hide how it works.

Syntax

Nouns for classes.
Verbs for functions.
Adjectives for interfaces.

Architecture

SOLID

• S ➤ One responsibility per item.
• O ➤ Extend, don’t modify.
• L ➤ If A extends B, A must be able to take B’s place.
• I ➤ Interfaces should be client specific.
• D ➤ Depend upon abstractions, not concretions.

Coupling and Cohesion

They are the same thing. The difference is that the latter has some though behind it.

Demeter, don’t ask

Units (i.e. classes) should talk to one another only if they share the same concern, and in such a way that leaves them ignorant of one another’s inner workings.

Avoid changes in abstraction levels

They are hard to follow and indicate that something might need to be in a different layer.

Avoid generalizations

Only abstract code and generalize when clearly needed.
It’s easy to do but a pain to undo.

Don’ts

Don’t do a perfect job

Perfection is hardly relevant. A bad test is better than no test.
Don’t waste time and mental space on perfection.

Don’t follow the rules

Follow the principles.

Don’t be clever

Don’t get fancy.
Be clear and concise.

Don’t be an ‘architect’

Bug-less code with meh-architecture is better than awesome architecture with buggy code.

Don’t fear duplication

It’s better than poor abstraction.
Also, DRY is about avoiding duplicate logic or knowledge.
Duplicate lines might imply logic duplication, but they might not.

Don’t get sentimental

No emotional attachment to code. Not to yours, not to others.