3 ms·
I think it might come with experience. I definately gravitate to very small classses/functions, personally prefering classes to fit within a single screen. Obv
by XenophileJKO 8y ago
I think it might come with experience. I definately gravitate to very small classses/functions, personally prefering classes to fit within a single screen.
Obviously this isn't always achievable.
It comes down to: "What do you want to focus on?" Each drill down should be to a lower level of abstraction. It is seperating the what from the how.
It results in functions/classes that either detail a flow (set of decisions) or that implement actions. For example I generally don't need to know how to read a file from disk where I am trying to decide if I should read a file.
When looking at code you drill down in a very vertical fashion when you want to know "How does it do operation X?" Meaning the operation largely can be understood in isolation. There shouldn't be a lot of context that is required for it. A side-effect is that all the unit tests are very self contained.
This utlimately steers you towards a much more functional and compositional programming style. Certainly it is moving complexity around, but the end result is heavy compartmentalization and limiting the context required to understand any section of code.
- cmsj 8y agoI like your description of separating flow from actions, I try to do that too. I want my functions higher up the abstraction stack to read like they are orchestrating black boxes of functionality.