GitHubRepoSession.find_in_tags_via_graphql has a cyclomatic complexity of 17 with "high" risk264 return r.json()
265 return None
266
267 def find_in_tags_via_graphql(self, ret, pre_ok, major):268 """GraphQL allows for faster search across many tags.
269 We aggregate the highest semantic version among batches of 100 records.
270 In this way --major filtering results in much fewer requests compared to traditional APIGitHubRepoSession.get_release_from_feed has a cyclomatic complexity of 19 with "high" risk519 release["install_name"] = self.name
520 return release or None
521
522 def get_release_from_feed(self, pre_ok, major):523 """Get the latest release from the `releases.atom` feed."""
524 ret = {}
525 seen_semver = FalseBaseProjectHolder.sanitize_version has a cyclomatic complexity of 22 with "high" risk292 return True
293 return False
294
295 def sanitize_version(self, version_s, pre_ok=False, major=None):296 """
297 Extract a version from tag name; that satisfies this holder's filters, etc.
298main has a cyclomatic complexity of 52 with "critical" risk549 sys.exit(1)
550
551
552def main(argv=None):553 """
554 The entrypoint to CLI app.
555update_spec has a cyclomatic complexity of 21 with "high" risk377 return None
378
379
380def update_spec(repo, res, sem="minor"):381 print(res["version"])
382 if "current_version" not in res or res["current_version"] < res["version"]:
383 log.info("Updating spec %s with semantic %s", repo, sem)A function with high cyclomatic complexity can be hard to understand and maintain. Cyclomatic complexity is a software metric that measures the number of independent paths through a function. A higher cyclomatic complexity indicates that the function has more decision points and is more complex.
Functions with high cyclomatic complexity are more likely to have bugs and be harder to test. They may lead to reduced code maintainability and increased development time.
To reduce the cyclomatic complexity of a function, you can:
- Break the function into smaller, more manageable functions.
- Refactor complex logic into separate functions or classes.
- Avoid multiple return paths and deeply nested control expressions.
Bad practice
def number_to_name():
number = input()
if not number.isdigit():
print("Enter a valid number")
return
number = int(number)
if number >= 10:
print("Number is too big")
return
if number == 1:
print("one")
elif number == 2:
print("two")
elif number == 3:
print("three")
elif number == 4:
print("four")
elif number == 5:
print("five")
elif number == 6:
print("six")
elif number == 7:
print("seven")
elif number == 8:
print("eight")
elif number == 9:
print("nine")
Recommended
def number_to_name():
number = input()
if not number.isdigit():
print("Enter a valid number")
return
number = int(number)
if number >= 10:
print("Number is too big")
return
names = {
1: "one",
2: "two",
3: "three",
4: "four",
5: "five",
6: "six",
7: "seven",
8: "eight",
9: "nine",
}
print(names[number])
Issue configuration
Cyclomatic complexity threshold can be configured using the
cyclomatic_complexity_threshold meta field in the
.deepsource.toml config file.
Configuring this is optional. If you don't provide a value, the Analyzer will
raise issues for functions with complexity higher than the default threshold,
which is medium for the Python Analyzer.
Here's the mapping of the risk category to the cyclomatic complexity score to help you configure this better:
| Risk category | Cyclomatic complexity range | Recommended action |
|---|---|---|
| low | 1-5 | No action needed. |
| medium | 6-15 | Review and monitor. |
| high | 16-25 | Review and refactor. Recommended to add comments if the function is absolutely needed to be kept as it is. |
| very-high | 26-50 | Refactor to reduce the complexity. |
| critical | >50 | Must refactor this. This can make the code untestable and very difficult to understand. |