|
|
|
|
|
|
by slowmovintarget
3578 days ago
|
|
|
There are a number of objective measures of cyclomatic complexity in software. These metrics show that the higher the complexity, the lower the cohesion of the code[1]. Code that is complex, and has low cohesion, is harder to understand, and therefore harder to change. It's the elephant you have to push on every time you want your program to do something new[2]. [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity
[2] https://www.youtube.com/watch?v=rI8tNMsozo0
"Dependency hell" might be subjective, but tools that reduce the upfront cost of increased dependencies don't remove the other burdens from you, the developer. In fact they often allow you to produce an impenetrable, unrecoverable tangle more quickly than doing without them.Edit: Just realized who I responded to... "But, you knew all that." |
|
|
So, what's interesting is, I would often consider many small bits to have a _lower_ cyclomatic complexity number. That is, whenever I've used tools that measure this kind of thing, the solution is always to take the big things and break them up into many, smaller bits. It's possible that this is bias in the tooling, though.
I think some of this comes down to individual preference as well. It's like that joke, would you rather fight one horse-sized duck or 100 duck-sized horses? In this admittedly very stretched metaphor, the former are relatively monolithic codebases, and the latter are relatively modular ones. I know that I used to prefer one hundred-line class to ten ten-line classes, but now, much much prefer the latter. My experience talking to people about this is that people fall somewhere on this line, often in different places, and that makes it harder to understand. The action that I'm taking to reduce complexity can often be perceived as increasing complexity, depending on where the other person falls on that line.