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. 
- List item