Writing small code

This talk is great by @mark_menard and if you are into the topic of writing clean code, then you should see it. The examples are super! I wrote some notes for further reference which you can find below:

The great thing about writing shitty code that just works is that it is too risky and expensive to change, so it lives forever. – Reginald Braithwaite

We should write good code because we don’t know what the future will bring. How the requirements will change, how the team will evolve, etc. Therefore our goal should be to write small units of code that are amenable to change.

Writing good code is an iterative process. You just don’t simply write good code on a whim. You write it a first time and then you refactor it until it looks solid.

Tools that can be used to write small units of code:

Golden rule of writing methods: done one thing; do it well; do only that thing. Rule of thumb: if all of the statements are in the same level of abstraction than the method follows the golden rule.

How to write small classes? it should have one responsibility. it should have small methods. the abstraction should be cohesive throughout the class.

When should I consider refactoring? When making a change hurts.

Too much conditional statements in a method are a code smell. We use conditional statements to hide abstractions. Therefore, if you have a lot of them you probably missed one abstraction.

While writing code you should depend on the abstraction not on the concretion. Therefore one should take advantage of duck typing.

In order to properly isolate abstractions we should isolate the what from the how. The how should be moved to the collaborators of the class and then that class only takes care of the coordination.