Source Code Metric
3-1] Cyclomatic Complexity (Function)
3-2] Number of Call Levels (Maximum depth of nesting of conditionals, etc. within functions)
3-3] Number of Function Parameters
3-4] Number of Calling Functions
3-5] Number of Called Functions
3-6] Number of Executable Code Lines
I am using SonarQube Community Edition 8.9.7, and my target code is C++.
I was wondering if this can be measured in the Developer Edition.
Since you’re asking for new(?) rules, I’ve moved this to the New rules category. There’s a template in that category, with the information necessary to consider a new rule. I’ll repeat it here for your convenience:
Post template
Please follow this template to help us specify this new rule:
description of the Rule. It should answer questions “why is there an issue?”, “what could be its impact?” and “what could happen in case of a successful attack?” (for Vulnerabilities and Security Hotspots)
snippet of Noncompliant Code
snippet of Compilant Code (fixing the above noncompliant code)
exceptions to the Noncompliant Code, i.e. conditions in which the noncompliant code should not raise an issue so that we reduce the number of False Positives.
external references and/or language specifications
Examples of real open source projects that have been impacted by this issue and fixed it (eg: link to the commit fix / CVEs for security rules / etc)
Documentation/Blog post explaining the issue and what should be done instead.
type : Bug, Vulnerability, Code Smell, Security Hotspot?
Tags
Guidelines:
We want to add as many valuable rules as possible. Thus we have guidelines to help us see the value of a rule and decide if it should be implemented. Please read them before submitting your rule:
Is the rule useful for a developer.
If the rule is a Bug, Code Smell or Vulnerability it should ask the developer to fix a real problem. It shouldn’t raise warnings asking for a manual review.
If the rule is a Security Hotspot, it should ask the developer to review a security sensitive piece of code. It should raise a reasonable number of issues so that developers don’t feel overwhelmed. The goal in this case is to guide code reviews.
Does the rule describe enough exceptions, i.e. code on which the rule doesn’t apply? Rules should avoid False Positives even if it creates some blind spots, otherwise developers will stop using SonarQube/SonarCloud/SonarLint. You can check this by looking at open-source projects.
We put a higher priority on rules valuable to every developer. For example we avoid adding more style rules as each style guide is different.
We avoid bug rules which raise on syntax errors. There is little value in duplicating compilers’ behavior.
Don’t hesitate to share rule ideas. Even when they don’t match our guidelines it might make somebody else think of an alternative rule.
That said, as a current user, have you taken a look at what’s already available to you? Becuase Cyclomatic Complexity certainly is.
Okay. Sorry. I’ve moved your post back to the SonarQube category.
CWE-659 is an aggregation of nearly 100 granular rules. I wouldn’t be surprised if no one supported all the pieces. The rules site can help you investigate which pieces are or are not covered.
I can tell you off-hand that there are rules for maximum Cyclomatic Complexity in a function / method and for too many parameters. There’s also a rule for too many lines of code in a file.