Nice article but I think there's something missing. Some things are uniformly bad like multi-screen methods or methods with six levels of nested conditionals, b

Nice article but I think there's something missing. Some things are uniformly bad like multi-screen methods or methods with six levels of nested conditionals, but the shape of code isn't really uniform. You can't look at the class or method level and play the three bears game (this porridge is too hot, too cold, just right). In codebases, the ratio of big to small matters. It's fine to have some of those classes that seem too small. They are a natural consequence of good structuring. As well, it's okay to have a few large classes also, ones that you know could be broken down but not convincingly. The thing that's awful is that if you say this sort of thing people want to believe that it's license to allow classes and methods to grow without bound, but it isn't. If you aim for understandability, you'll have code with sizes that fall into a distribution, usually power-law-ish https://researchspace.auckland.ac.nz/bitstream/handle/2292/16834/Understanding%20the%20shape%20of%20Java%20software.pdf?sequence=2 https://researchspace.auckland.ac.nz/bitstream/handle/2292/1...