Well, that is an unproven hypothesis. From my experience, however, this is true. Ayende Rahien has found similarities to my hypothesis.
Let’s extend this hypothesis – less code is better – a little bit further. The widespread assumption is that increasing the complexity of an application is bad. Why? Because lower maintainability means a slowdown in development which, as a consequence, increases the development costs. So, is it then better to keep complexity low and write more code instead?
Looks like with a smaller code base the complexity tends to explode (blue). On the other hand, even with a larger code base (red), the complexity seems to stay more or less the same.
Ayende says: „But the above chart is somewhat misleading because it makes the hidden assumption that in both code styles (bigger vs. smaller), you’ll have the same amount of code, which is obviously false. Here is what is probably a more accurate representation of how much code is written for [one of both] style[s] per # of features.“
More realistically it looks like this:
Ok, that sounds nice, but how does that work in practice?
- Part 2: Destructuring and Arrow Function. How can you use that (well-known) language behaviors.
- Part 3: Magic Getter/Setter and Variable Function Names. Uh, uh? Self-modifying code?!
- Part 4: Directory indexes and TypeScript initialization shorteners.
PS: It’s not lost on me that my hypothesis „the shorter, the better“ does not apply to this article, especially, when I had to split it up in four parts to increase the “readability“. Point taken, hope you enjoy it nonetheless.