Comments (3)
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?
from mccabe.
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!
from mccabe.
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!
from mccabe.
Related Issues (20)
- Config: Ignore local functions HOT 1
- Allow setting max complexity per function HOT 1
- [docs] Incorrect date on release note for 0.7.0 HOT 1
- Improve error message on invalid use: `python -m mccabe`
- Error code when there are functions with complexity greater than the threshold
- Add support for pytest 7+ HOT 2
- Use setuptools.build_meta HOT 1
- [Proposal] Add Cognitive Complexity as new option
- ignore guard clauses HOT 2
- "U" mode is no longer accepted from Python 3.9
- state project maintenance status HOT 2
- mccable should allow ranged noqa exceptions HOT 3
- optparse 'type' option no longer accepts strings HOT 1
- install offline mccabe with error HOT 1
- Release mccabe > 0.6.1 to remove pytest-runner requirement? HOT 1
- Some way to ignore specific marked branches for the purposes of the complexity measure HOT 1
- 0.7: test failure HOT 5
- [Proposal] Add a check for none/multiple positional arguments
- GitHub Action HOT 1
- [Proposal] Allow disabling "try-except" clauses evaluation. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mccabe.