4 ms·

This is somewhat similar to the concept of “Cyclomatic Complexity”, which is the number of independent paths though a piece of code, and can be statically analy

by jakear 8y ago

This is somewhat similar to the concept of “Cyclomatic Complexity”, which is the number of independent paths though a piece of code, and can be statically analyzed. https://en.m.wikipedia.org/wiki/Cyclomatic_complexity https://en.m.wikipedia.org/wiki/Cyclomatic_complexity

danabramov 8y ago
Note one difference is that I'm talking about characteristics of an API, not particular code snippet. Although it's relevant.
amelius 8y ago
This makes me wonder, are software metrics still a thing?
- rbanffy 8y ago
  Yes. At least for me.
jerf 8y ago
I like this concept better than cyclomatic complexity, precisely because this is what cyclomatic complexity is trying to poorly approximate. But it can't be automatically derived in the general case, or even terribly easily in non-general cases, either, unlike cyclomatic complexity. I use a descendant of gometalinter on all my Go code, and one of the things it ships with is cyclomatic complexity, and I always turn it off. Precisely because I tend to think like this, it often gives my code terribly wrong ratings because it can't see that there's actually only a finite set of paths through the code that are possible, and also as the blog post demonstrates, sometimes adding more code actually simplifies the conceptual flow. But cyclomatic complexity will generally say the "more code" is even more cyclomatically complex. There's also some Go-specific elements to my distaste for the measure, though; since in Go right now handling an error is automatically an if statement, that'll hit you right in the metrics. But in many cases, something, err := GetSomething() if err != nil { return errwrap.Wrapf("while trying to get something: {{err}}", err) } Officially that's an if statement; unofficially, it ought to be a cyclomatic complexity of zero. Now, it isn't technically a free if clause, in the sense that a bug could live there, but if you're going to count the exception-based equivalent as zero (and it has the same callout; bugs can lie in your exception handling exactly the same way), then this ought to be practically zero too. Consequently, Go functions tend to get smacked with much higher complexity numbers than exception-equivalent code. Yeah, it's probably not a one-to-one, but it's certainly not as lopsided as the metric makes it seem.
- sigil 8y ago
  Does gometalinter report absolute cyclomatic complexity numbers, or does it report density (cyclomatic complexity / sloc)?

by jakear 8y ago

danabramov 8y ago

Note one difference is that I'm talking about characteristics of an API, not particular code snippet. Although it's relevant.

amelius 8y ago

This makes me wonder, are software metrics still a thing?

rbanffy 8y ago
Yes. At least for me.

jerf 8y ago

I like this concept better than cyclomatic complexity, precisely because this is what cyclomatic complexity is trying to poorly approximate. But it can't be automatically derived in the general case, or even terribly easily in non-general cases, either, unlike cyclomatic complexity. I use a descendant of gometalinter on all my Go code, and one of the things it ships with is cyclomatic complexity, and I always turn it off. Precisely because I tend to think like this, it often gives my code terribly wrong ratings because it can't see that there's actually only a finite set of paths through the code that are possible, and also as the blog post demonstrates, sometimes adding more code actually simplifies the conceptual flow. But cyclomatic complexity will generally say the "more code" is even more cyclomatically complex. There's also some Go-specific elements to my distaste for the measure, though; since in Go right now handling an error is automatically an if statement, that'll hit you right in the metrics. But in many cases, something, err := GetSomething() if err != nil { return errwrap.Wrapf("while trying to get something: {{err}}", err) } Officially that's an if statement; unofficially, it ought to be a cyclomatic complexity of zero. Now, it isn't technically a free if clause, in the sense that a bug could live there, but if you're going to count the exception-based equivalent as zero (and it has the same callout; bugs can lie in your exception handling exactly the same way), then this ought to be practically zero too. Consequently, Go functions tend to get smacked with much higher complexity numbers than exception-equivalent code. Yeah, it's probably not a one-to-one, but it's certainly not as lopsided as the metric makes it seem.

sigil 8y ago
Does gometalinter report absolute cyclomatic complexity numbers, or does it report density (cyclomatic complexity / sloc)?