[openstack-dev] [all] cyclomatic complexity check in flake8 & Python 3
Sean Dague
sean at dague.net
Tue Dec 12 13:40:28 UTC 2017
On 12/12/2017 08:08 AM, Thierry Carrez wrote:
> Zane Bitter wrote:
<snip>
>> Here's how the allegedly most complex function in Heat[5] shakes out,
>> for example:
>>
>> mccabe py27 py36
>> 0.2.1 14 6
>> 0.3.1 23 23
>> 0.6.1 23 23
>>
>> I don't have a solution to suggest, but I burned most of my day digging
>> into this so I just wanted to let y'all know how screwed we are.
> Thanks for digging into this, Zane. I'd say we have two options, based
> on how useful running those tests is:
>
> 1/ If they are useful, we should bump the version, at the same time
> adjusting max-complexity per repo to match the most complex function
> (with some slack factor). Encourage more projects to use cyclomatic
> complexity checks and fix the biggest offenders using cycle goals.
>
> 2/ If they are not useful, just drop cyclomatic complexity tests overall
> rather than relying on wrong results and wasting CPU cycles
>
> So I'd like to hear from the 60+ repos on whether using those tests lead
> to any good results :)
I don't know how useful these end up being (#1), though I've seen
patches from time to time with people trying to reduce them.
The current max in Nova is 35. Moving to mccabe 0.6.1 generates 2 errors:
Running flake8 on all files
./nova/compute/manager.py:763:5: C901 'ComputeManager._init_instance' is
too complex (37)
./nova/tests/functional/api_samples_test_base.py:144:5: C901
'ApiSampleTestBase._compare_result' is too complex (36)
I honestly think this is one of the things that you declare a flag day a
couple weeks out, warn everyone they are going to have to adjust their
max, and move forward. It's a very easy fix when pep8 starts failing people.
-Sean
--
Sean Dague
http://dague.net
More information about the OpenStack-dev
mailing list