4 ms·

I wonder whether it would be possible to make a lint-like verifier which rejected code whose local complexity exceeded some objective thresholds. I imagine it

I wonder whether it would be possible to make a lint-like verifier which rejected code whose local complexity exceeded some objective thresholds. I imagine it would be pretty easy to come up with an objective measure of pure control flow complexity, but the complexity of interactions between control and data would be harder to quantify.

eru 14y ago
Interesting idea. Instead of aiming for something hard and true, you can probably find a good proxy of complexity fairly easily. Once you have it, just don't confuse the map with the territory; but use it as a hint to see what code to investigate. Global complexity might not be much harder to measure than local complexity, perhaps even easier. Look for interdependencies.
TimGebhardt 14y ago
At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20. It's a C#/.NET project so we use NCover as part of the automated build. NCover has a reporting tool that you can set to return a non-zero return value (which will fail most build systems) if it's metrics exceed some value -- in this case class-level cyclomatic complexity exceeding 20. I've thought about ratcheting it down to 15 based on stuff I've read, but unfortunately that particular failure metric can only be set as low as the class-level in the latest version. The next version (4.0) will have the ability to set the threshold at the method level. In any case, I'd rather have a handful of places in the code where someone has to do something goofy to work around that metric rather than accidentally allow the whole project's complexity to creep up as time goes on.
- cpeterso 14y ago
  > At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20. Are your co-workers cool with that? Complexity metrics are a little "squishy", but the costs of a broken build are large.
djcb 14y ago
There's the 'pmccabe' tool, which can check for # of lines of functions and their cyclomatic complexity. Then, pmccabe `find . -name '*.c'` | sort -nr | awk '($1 > 10)' gives me all functions that have a cyclomatic complexity over 10; I often add it as a target in a Makefile, so I can easily check this. Similar, for functions of a certain length.
cpeterso 14y ago
Tools for measuring code "complexity" already exist. Cyclomatic Complexity is a popular metric: https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity checkstyle is a Java lint that, among other things, can check code complexity: http://checkstyle.sourceforge.net/config_metrics.html http://checkstyle.sourceforge.net/config_metrics.html

eru 14y ago

Interesting idea. Instead of aiming for something hard and true, you can probably find a good proxy of complexity fairly easily. Once you have it, just don't confuse the map with the territory; but use it as a hint to see what code to investigate. Global complexity might not be much harder to measure than local complexity, perhaps even easier. Look for interdependencies.

TimGebhardt 14y ago

At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20. It's a C#/.NET project so we use NCover as part of the automated build. NCover has a reporting tool that you can set to return a non-zero return value (which will fail most build systems) if it's metrics exceed some value -- in this case class-level cyclomatic complexity exceeding 20. I've thought about ratcheting it down to 15 based on stuff I've read, but unfortunately that particular failure metric can only be set as low as the class-level in the latest version. The next version (4.0) will have the ability to set the threshold at the method level. In any case, I'd rather have a handful of places in the code where someone has to do something goofy to work around that metric rather than accidentally allow the whole project's complexity to creep up as time goes on.

cpeterso 14y ago
> At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20. Are your co-workers cool with that? Complexity metrics are a little "squishy", but the costs of a broken build are large.

djcb 14y ago

There's the 'pmccabe' tool, which can check for # of lines of functions and their cyclomatic complexity. Then, pmccabe `find . -name '*.c'` | sort -nr | awk '($1 > 10)' gives me all functions that have a cyclomatic complexity over 10; I often add it as a target in a Makefile, so I can easily check this. Similar, for functions of a certain length.

cpeterso 14y ago

Tools for measuring code "complexity" already exist. Cyclomatic Complexity is a popular metric: https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity checkstyle is a Java lint that, among other things, can check code complexity: http://checkstyle.sourceforge.net/config_metrics.html http://checkstyle.sourceforge.net/config_metrics.html