This is the Fifteenth Step towards gaining the Programming Enlightenment series. If you didn’t learn the Fourteenth Step, read it.
“Bad programmers worry about the code.
Good programmers worry about data structures and their relationships” ~ Linus Torvalds
Reason yourself or question your actions, is what everybody should do, be it in life or at work. This applies equally to the coding. We constantly have to push feature in production as needed by the business. As this business decision comes into coding, it may or may not totally be realized into a product. That’s where the reasoning or questioning the implementation comes into place.
How to reason your code?
Be it for a already implemented feature or developing a new one, we should start from the smallest chunk that we can work at a given time. It can be a single statement to a block which is within a method call. We need to reason the existence of each statement playing devil’s advocate with self or with a peer.
“(There’s) no such thing as a stupid question”. ~ Carl Sagan.
Why reason your code?
Reasoning your code leads to us wearing a different hat and seeing from a different perspective. Many a times, just talking about the problem with your peer, may strike you with some Eureka moment, and the solution just is there. Also, we can try to shoulder QA’s responsibility and evaluate the endpoint properties with precondition and post-condition.
This will help us make the code modular into single independent sections, where the bugs can be traced easily or can be made bug free.
Tips on How to reason your code?
Unsurprisingly, most of the tips mentioned can be checked by static code analyzers.
- Avoid using goto statements, as they make remote sections highly interdependent.
- Avoid using modifiable global variables, as they make all sections that use them dependent.
- Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage.
- Make objects immutable whenever relevant.
- Make the code readable by using spacing, both horizontal and vertical. For example, aligning related structures and using an empty line to separate two sections.
- Make the self-documenting code by choosing descriptive (but relatively short) names for objects, types, functions, etc.
- Avoid nested section, if you need one, make it a function.
- Make your functions short and focused on a single task. The old 24-line limit still applies. Although screen size and resolution have changed, nothing has changed in human cognition since the 1960s.
- Functions should have few parameters (four is a good upper bound). This does not restrict the data communicated to functions: Grouping related parameters into a single object benefits from object invariants and saves reasoning, such as their coherence and consistency.
- More generally, each unit of code, from a block to a library, should have a narrow interface. Less communication reduces the reasoning required. This means that getters that return internal state are a liability — don’t ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, encapsulation is all — and only — about narrow interfaces.
- In order to preserve class invariants, usage of setters should be discouraged, as setters tend to allow invariants that govern an object’s state to be broken.
TL;DR You may seem stupid for a while, but reasoning your assumptions will always help in bettering our code and our intuitions.
Go to Sixteenth Step.
Go to the next path (Coming soon).
References:
- 97 things Every Programmer Should Know ~ Git Book
- 97 Things Every Programmer Should Know ~ Paperback
- Why is 24-line limit? ~ Stack exchange
- List of Static Code Analysis Tool ~ Wiki
- Tips on doing a better Code-Review ~ Github blog
