Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Software Complexity: What Metrics to Use?

thevaluable.dev

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Measuring Software Complexity: What Metrics to Use?

#51

Post by streamofdigits »

okl wrote: post #19
streamofdigits wrote: post #12

The Einstein quote is that "something should be a simple as needed but no simpler", but how to be pin down "required" in an objective / quantifiable way? Somehow it is more important to measure "gratuitous" complexity, redundant complexity that is not justified by present or plausible future requirements... The problem is that the code itself does not capture requirements, so code analysis can give you absolute indic…

Isn't the general goal rather to avoid/eliminate overly complex cruft (that every programmer should be able to recognize) than to find the maximally simple solution to a problem?

that seems like a more tractable goal if confined to local analysis (something like lines of code in a function or file unit) but people generally try to come up also with overall complexity that seems harder

Re: Measuring Software Complexity: What Metrics to Use?

#52

Post by marcosdumay »

pfdietz wrote: post #44

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.

AFAIK the one unambiguously relevant metric for how many bugs you will find in a codebase is how many its "clients" define as acceptable.

Any kind of internal code quality affects the productivity of the debugging procedure, not the final number of bugs.

Re: Measuring Software Complexity: What Metrics to Use?

#53

Post by sobkas »

pydry wrote: post #16
hacoo wrote: post #7

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:…

Couldnt yout just raise the threshold by tweaking the config with your PR instead? I do this all the time with other automated checkers (linters, etc.). I don't see why this should be different. If another human agrees it shouldnt be a problem.

Because if you change that config file, people responsible for it will be added to review, and will beat you with a stick for touching it without consulting change with them?

Re: Measuring Software Complexity: What Metrics to Use?

#54

Post by throwaway81523 »

juancb wrote: post #48
throwaway81523 wrote: post #10

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?

I think that doesn't count, as long as the install is in one piece. That's how Python got its popularity. Its "batteries included" approach meant you got lots of stuff in the stdlib instead of having to chase it all over the interweb. Unfortunately they seemed to have abandoned that approach in more recent times.

Re: Measuring Software Complexity: What Metrics to Use?

#55

Post by hutzlibu »

flaratt_ljos wrote: post #6

There are a lot of things you can do to lower these sort of metrics without addressing actual complexity, sweeping the problem under the rug. Perhaps a better metric for software complexity would be the amount of work the computer has to do, or the number of instructions it has to execute.

"Perhaps a better metric for software complexity would be the amount of work the computer has to do"

By that definition a loop doing 1 billion times a simple calculation would count as very complex, even though it is very easy to understand.

LOC would be better, even though code can be dense and complivated, or very verbose and simple.

Re: Measuring Software Complexity: What Metrics to Use?

#56

Post by hutzlibu »

Forge36 wrote: post #30
hacoo wrote: post #7

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.

Sounds like a place to leave as soon as possible.

Unless the tool just meassured for amount of change and flagged it for review, which might make sense, as you can also mess up by removing things, you think are unused.

Re: Measuring Software Complexity: What Metrics to Use?

#57

Post by oblak »

exabrial wrote: post #43

The number one metric: Consistency. If an app is similar to itself in all places, it's very easy to understand. Better yet, if it's similar and consistent with how other things have been built, we can call it "clean code". Back in the day we called these things architecture, but I'm old and salty.

What if the code is consistently crappy and complex all around. Would that make it simple? Trick question, old man. It would not. I am not exactly young but damn I am sweet

Re: Measuring Software Complexity: What Metrics to Use?

#58

Post by bradgessler »

hacoo wrote: post #7

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.

Re: Measuring Software Complexity: What Metrics to Use?

#59

Post by kitd »

kello wrote: post #37
cjfd wrote: post #2

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.

second this. toolchain complexity is way more of a PITA than code complexity for me these days.

Toolchain simplicity is a key reason for why I like Go. One binary to do it all.

Re: Measuring Software Complexity: What Metrics to Use?

#60

Post by jackblemming »

oblak wrote: post #57
exabrial wrote: post #43

The number one metric: Consistency. If an app is similar to itself in all places, it's very easy to understand. Better yet, if it's similar and consistent with how other things have been built, we can call it "clean code". Back in the day we called these things architecture, but I'm old and salty.

What if the code is consistently crappy and complex all around. Would that make it simple? Trick question, old man. It would not. I am not exactly young but damn I am sweet

You're not wrong. "Consistency" is a poorly defined principle and basically used to justify "what I'm doing is good (consistent). What you're doing is bad (inconsistent)"

And it was called Uniformity back in the day, not "architecture".

A better name for "consistency" is "following project conventions" which IS well defined.

Post reply on HN