Cyclomatic complexity metric practices for Python

Question

I have a relatively large Python project that I work on, and we don't have any cyclomatic complexity tools as a part of our automated test and deployment process.

How important are cyclomatic complexity tools in Python? Do you or your project use them and find them effective? I'd like a nice before/after story if anyone has one so we can take a bit of the subjectiveness out of the answers (i.e. before we didn't have a cyclo-comp tool either, and after we introduced it, good thing A happened, bad thing B happened, etc). There are a lot of other general answers to this type of question, but I didn't find one for Python projects in particular.

I'm ultimately trying to decide whether or not it's worth it for me to add it to our processes, and what particular metric and tool/library is best for large Python projects. One of our major goals is long term maintenance.

Answer 1

We used the RADON tool in one of our projects which is related to Test Automation.

RADON

Depending on new features and requirements, we need to add/modify/update/delete codes in that project. Also, almost 4-5 people were working on this. So, as a part of review process, we identified and used RADON tools since we want our code maintainable and readable.

Depend on the RADON tool output, there were several times we re-factored our code, added more methods and modified the looping.

Please let me know if this is useful to you.

Answer 2

Python isn't special when it comes to cyclomatic complexity. CC measures how much branching logic is in a chunk of code.

Experience shows that when the branching is "high", that code is harder to understand and change reliably than code in which the branching is lower.

With metrics, it typically isn't absolute values that matter; it is relative values as experienced by your organization. What you should do is to measure various metrics (CC is one) and look for a knee in the curve that relates that metric to bugs-found-in-code. Once you know where the knee is, ask coders to write modules whose complexity is below the knee. This is the connection to long-term maintenance.

What you don't measure, you can't control.