3 ms·

Wow, that's a good list. I agree with all of those, and am bookmarking this to show to others. On the subject of deep modules, as also recommended by John Oust

by whstl 3y ago

Wow, that's a good list. I agree with all of those, and am bookmarking this to show to others. On the subject of deep modules, as also recommended by John Ousterhout, I also enjoy a side effect of this approach: flatter dependency trees (internal dependencies). If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things. Not needing this makes it easier to debug and understand the big picture. IMO, "big picture code readability" is something of an afterthought. Things like Clean Code only care about the "small picture", individual classes and methods. Things that are rarely a problem in practice IMO. Flatter hierarchies also reduces the number of things to maintain/understand: in the frontend, for example, a flat component hierarchy removes the need for components far away in the hierarchy to communicate, so no need for Redux (also no prop-drilling). It also makes things like DI containers not strictly necessary, as you can easily do it manually, if you have fewer layers. Another important thing I realized is flatter hierarchies allow making that dependency graph closer to a tree, rather than a cyclic graph. This reduces cross-cutting concerns and minimizes incidences of "surprise code" that are often super deep into the dependency tree and a common source of bugs. All IMO and IME, of course. But I'm curious if you also share my experience.

082349872349872 3y ago
> If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things. I'm a big fan of being able to read stack traces without scrolling, so my rules of thumb are to remove layers that pass data around without either providing a substantial abstraction or doing some computation with it (avoid ravioli code), and to collapse layers that were all doing the same sort of thing to the data, each a little bit at a time (avoid salami code). My bet is that shallow modules originate via Conway's Law, then get cargo culted.
- sam_bristow 3y ago
  Every layer of indirection needs to earn its keep. I hate working in codebases which are full of indirection without abstraction, you spend so long hunting for the bit of code that actually _does_ something.
  - PH95VuimJjqBqy 3y ago
    > Every layer of indirection needs to earn its keep. So much this. One of the things I absolutely hate seeing are the use of interfaces with a single concrete implementation. context matters, it makes sense if you're authoring a library, it can make sense if you're working in something overly dynamic such as Ruby, Python, et al, but in a language like C#, Java, C++, et al, the compiler will assist you if you ever find yourself needing a second concrete implementation and most likely if you DO end up needing that second implementation, the interface is going to change anyway.

by whstl 3y ago

082349872349872 3y ago

> If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things. I'm a big fan of being able to read stack traces without scrolling, so my rules of thumb are to remove layers that pass data around without either providing a substantial abstraction or doing some computation with it (avoid ravioli code), and to collapse layers that were all doing the same sort of thing to the data, each a little bit at a time (avoid salami code). My bet is that shallow modules originate via Conway's Law, then get cargo culted.

sam_bristow 3y ago
Every layer of indirection needs to earn its keep. I hate working in codebases which are full of indirection without abstraction, you spend so long hunting for the bit of code that actually _does_ something.
- PH95VuimJjqBqy 3y ago
  > Every layer of indirection needs to earn its keep. So much this. One of the things I absolutely hate seeing are the use of interfaces with a single concrete implementation. context matters, it makes sense if you're authoring a library, it can make sense if you're working in something overly dynamic such as Ruby, Python, et al, but in a language like C#, Java, C++, et al, the compiler will assist you if you ever find yourself needing a second concrete implementation and most likely if you DO end up needing that second implementation, the interface is going to change anyway.