4 ms·
I was hoping to also find mentions of how to effectively reduce these. When reading code, I break things down differently. 1. Domain knowledge 2. Programm
by karmakaze 5y ago
I was hoping to also find mentions of how to effectively reduce these.
When reading code, I break things down differently.
1. Domain knowledge
2. Programming knowledge (e.g. recursion)
3. What is being done
4. How is it being done
5. Where/when is it being done
Wherever possible I try to stay with strong opinions and alignment on the first three. The last two should try to be as simple and clear as possible. Reading code in this day and age should not so much be about 'playing computer' in your head, but rather using well-known/tested patterns that allow for factoring/composition and accurate reasoning without requiring deep context.
- joshbochu 5y agoIs it possible to accomplish the latter without the former?
- karmakaze 5y agoYes, instead of writing a custom for-loop use map/filter/reduce. Also make other things like this that fit either under computer-programming or domain knowledge. The interface/contract/behaviour of these 'known' parts can usually be made clear without unexpected side-effects. From then on, treat them as black-boxes. It's rare that I find mental capacity to be the limiting factor, rather than the unintentional obfuscation of the implementation. Perhaps this is just to say that the code itself is a source of incidental (aka accidental) complexity or confusion.
- joshbochu 5y agoTaking a quick glance at this comment again. I do plan on writing a few tactics to reduce confusion after I read (a programmer's brain) a bit more and can think more on it.