This talks about code complexity a lot. This, however, is not the chief source of complexity in many code bases. The number of tools needed to build things is the bane of the modern software developer. Also, the use of microservices where none are needed results in and enormous increase in complexity. Code complexity is relatively easy to fix compared to all of this.
I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier.
Ugh, no. I’ve worked in a codebase where CI would reject changes that had too much ‘code complexity’. You’d constantly have to find clever ways to split up your code, when doing so did not make sense, to appease the complexity checker. Oh yeah, and if you ever make a one-liner change, you might end up being forced to do a full refactor because that one line pushed the complexity threshold over the edge. The results:…
Did you also have the same feedback from your IDE? In other words would it have been less painful if you didn't have to suffer the long iteration times required to get feedback from some remote CI job?
The thing is that cyclomatic complexity for example (most popular complexity measure that linters use), it doesn’t make sense. Most of the time high cyclomatic complexity of a method is indicative of high business logic complexity… which is fine.
And dogmatically saying that methods shouldn’t have that many lines and branches and that you should just come up with better abstractions doesn’t help anyone, whereas having closely related functionality concentrated in a single place, rather than synthetically exploded into N different files, well this does help.
Ugh, no. I’ve worked in a codebase where CI would reject changes that had too much ‘code complexity’. You’d constantly have to find clever ways to split up your code, when doing so did not make sense, to appease the complexity checker. Oh yeah, and if you ever make a one-liner change, you might end up being forced to do a full refactor because that one line pushed the complexity threshold over the edge. The results:…
I was removing unused functionality, work became held up as the code complexity was too high (never mind I'd just reduced it). I don't know what tool they were using, and they didn't share the output. I asked them to document what they found, got a mouthful on this not being their responsibility.
There were attempts to predict bugs by looking at complexity metrics. As I recall, the research found that when you adjusted for code size, none of the metrics mattered. In other words, just use LOCs as your metric.
The real answers about complexity come from thinking about why we even care. It's because our feeble minds have to build internal models of the code so we can work with it. The cognitive aspects of building those models is why complexity matters. What things make it more difficult to build those models? A partial list, mostly as others have mentioned: - tool and library dependencies - nested conditions - loops and es…
I would argue complexity is also the wellspring of corner cases. The more corner cases, the more mercurial- and that isn’t just due to the limitations of our minds.
I didn't see anything on Function Point counts in the article. No advocating it per se but it was, at one time, considered one of the more useful ways to evaluate codebase complexity.
FP analysis is a measure for the "amount of functionality" not complexity. Maybe in relation to, e.g., the number of statements (statements/FP) it could make sense.
Number of function points is, given implementation language, strongly correlated with lines of code. Lines of code is, in turn, strongly correlated with all other complexity measures.
In other words, function point count is a measure of complexity.
Number of lines of code is a good metric for complexity. The hard part is estimating how many lines of code is reasonable for a specific feature. Some complexity is necessary. The problem is unnecessary complexity.
> Number of lines of code is a good metric for complexity. I don't agree with that premise. LOC are a metric for code size, not for complexity. I've found that in practice the number of statements is a more reliable indicator for code size than lines of code. (For typical imperative languages anyways.)
I propose a challenge, similar to the Obfuscated C challenge, to devise code that is impenetrable to the human mind and yet fantastically clean to all metrics.
Ugh, no. I’ve worked in a codebase where CI would reject changes that had too much ‘code complexity’. You’d constantly have to find clever ways to split up your code, when doing so did not make sense, to appease the complexity checker. Oh yeah, and if you ever make a one-liner change, you might end up being forced to do a full refactor because that one line pushed the complexity threshold over the edge. The results:…
I’ve found most CI checks like this are a crock. Forgot empty parentheses for that function definition with an arity of 0? Bzzzzzzzt! Sorry! Build failed. It’s just foolish. The only reason a CI should ever fail is if it catches a defect from making it into production.
> The only reason a CI should ever fail is if it catches a defect from making it into production.
Mechanical checks for things like formatting rules, linting errors, and reasonable tools to verify code complexity, as long as they don't produce false positives, are all important to run as part of CI.
Some blog linked from here (maybe jvns.ca?) made the case that depth of your project's software dependency tree is an important metric. The more crap you have to pull in, the more things can go wrong. You're better off with a large program with no dependencies, than a somewhat smaller program with a ton of dependencies. Language features on the other hand can let you develop complex programs quickly and reliably, by…
What about the depth of dependencies of any part of the standard libraries for a given language?
Isn't the standard library definitionally depth=1?