Make Things Small
If I were given the opportunity to speak a single sentence of advice to all the budding programmers in the world, I would need only three words: "Make things small."
Thankfully, here in this space I can also elaborate.
All other things being equal, code ought to have a fractal structure. That is, the general shape of the code should be scale independent. It should look similar regardless at which level you examine it.
Specifically, the code within any explicit logical boundary you might choose should consist of a bundle of one to several units at the next lower level.
I would assert that code structured in this way is optimized for understanding, testing, and evolution. And here my qualifier becomes relevant. All other things are not always equal. Sometimes it is necessary to optimize, or at least account for, other aspects.
Here are some of the other things that may not be equal from one boundary to the next:
When fractal structure conflicts with these constraints, then you have found the reason for compromise and pragmatism.
* Module roughly equates to a class, datatype, prototype, or object (or just a module, for languages that have them).
Thankfully, here in this space I can also elaborate.
All other things being equal, code ought to have a fractal structure. That is, the general shape of the code should be scale independent. It should look similar regardless at which level you examine it.
Specifically, the code within any explicit logical boundary you might choose should consist of a bundle of one to several units at the next lower level.
- An application should consist of one to several sub-systems.
- A sub-system should consist of one to several namespaces.
- A namespace should consist of one to several modules.*
- A module* should consist of one to several functions.
- A function should consist of one to several expressions.
- An expression should consist of one to several sub-expressions.
I would assert that code structured in this way is optimized for understanding, testing, and evolution. And here my qualifier becomes relevant. All other things are not always equal. Sometimes it is necessary to optimize, or at least account for, other aspects.
Here are some of the other things that may not be equal from one boundary to the next:
- Time constraints
- Resource (memory/storage/processing) constraints
- Consumer expectations
- Dependency APIs
When fractal structure conflicts with these constraints, then you have found the reason for compromise and pragmatism.
* Module roughly equates to a class, datatype, prototype, or object (or just a module, for languages that have them).