heuristics & software development
There are various heuristics we use to drive towards the north star of clean code. Some classics include :
- Writing files with no more than
nLOC (very controversial)
- One File per Class
- Don't Repeat Yourself
- Build components that are self contained & independent
I recently realized why these conventions even arise in the first place. It all stems from laziness.
It is much more efficient to tell someone what to do, than to have them go figure it out
It's virtually useless to tell someone to "go and write clean code". Some would ask "What exactly do you mean by that?".
To aim for clean code is to aim for an abstract concept. These heuristics ground that aim in actionable tasks.
How can a file be cleaned? We can start by checking a couple of things:
- is it a large file?
- are these methods too alike?
- is the language being used idiomatically?
Addressing these concerns will slowly chip away at complexity, and in their sum can tend to result in clean enough code.
Reading complex code is mentally tolling
Complexity is reviled. Ask any developer, "Would you rather work on a legacy spaghetti monolith, or a well oiled project?". None will opt for the spaghetti monolith, because the well oiled project is easier to work with.
These heuristics are guide rails when looking to reduce the complexity of your software. Determining the right combination and timing of these tricks is part of the essential trade of the software engineer.