A flag to treat inner functions as separate from outer function about mccabe

[sigmavirus24]

Hi there @kern3l

Thanks for the suggestion! This is valuable input and the request here seems reasonable. I took a look over https://en.wikipedia.org/wiki/Cyclomatic_complexity since I haven't looked at it in a few years. One thing that stuck out to me was

One of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.

Based on the spirit of the calculation (i.e., to reduce the complexity of routines - a.k.a, functions) I'm starting to wonder if adding the flag would counteract the benefits of running mccabe. Specifically, nested functions might not contribute to logical branches in a function, however, they do contribute to the complexity as far as other people are considered when reading the same code. Further, if you look at mccabe as a calculation of the number of different tests you might need to write to exercise all the code inside a routine/function, then you must consider nested functions as well.

In short, I'm leaning towards not adding a flag for this use-case. It seems to run counter to what the complexity calculation is trying to measure and the usefulness of the calculation. Does that make sense to you?

[JanChec]

Thanks for the answer! I completely agree that in the default mode the inner function should be counted as a part of the main function. Reasons:

• the chosen granularity here is functions
• inner functions are part of the outer functions
• there's no way to use (or test) inner functions directly

I'm sure you know how it is when you're putting a product out there and end users have different needs and ideas how the product should behave, often missing its scope by some margin. If feedback seems reasonable, then, as a programmer, there's always this set of questions:

• are my assumptions correct how core functionality should work?
• is it reasonable to allow modification of core behaviour to satisfy the need?
• ^ = how big is the group that wants the change vs how hard it would be to develop and maintain?
• are there any suitable workarounds?

Myself, I use your program to automatically block unreadable crap from even reaching code review. Readability is my main concern and testability is highly correlated with that. Heh, at this point I convinced myself that adding noqa in such cases is better, because it shows that something is wrong here, which is: the code is probably not tested enough automatically. At some times it's fine, but not always.

I hope that someone will find this input valuable. Cheers!

[sigmavirus24]

Thank you for your understanding and your incredibly valuable feedback!

I absolutely agree that if more people comment here in support of this (because while I appreciate reactions, they provide 0 visibility into the popularity of an issue), we can definitely reconsider this.

Myself, I use your program to automatically block unreadable crap from even reaching code review. Readability is my main concern and testability is highly correlated with that.

I'm glad to hear mccabe is helping with that. It's always good to hear that we're helping you improve the quality of the code you're maintaing just like it helps us.

Thank you again!