-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A flag to treat inner functions as separate from outer function #60
Comments
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
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? |
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:
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:
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 I hope that someone will find this input valuable. Cheers! |
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.
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! |
Hey!
When I have a function with several helper functions, I want to group them in a common context for readability. If only the main function is called from outside and all those helper functions are just readability helpers (so this main function isn't huge), this gives me:
Then I create a function with inner functions:
_run()
that is the highest abstraction level inner functionreturn _run()
Details why this is probably the best solution here: https://stackoverflow.com/questions/50253517/how-to-group-functions-without-side-effects
The problem is that currently
mccabe
sums up every inner function complexity with outer function complexity and outputs this as only one, huge result. Please consider:(sorted for readability)
I'd love if there was a flag to treat inner functions as separate from outer function.
The text was updated successfully, but these errors were encountered: