New rule: Magic numbers (or literals) should be replaced with symbolic constants
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
No implementation files, tests, or entry points are named in the issue. Start by locating the Java rule implementations in this SonarQube Delphi plugin and comparing their test structure. Done means a new rule reports non-exempt magic literals and covers the documented examples and exceptions with tests.
Written by the indexing model from the issue text.
Description
Prerequisites
- This rule has not already been suggested.
- This should be a new rule, not an improvement to an existing rule.
- This rule would be generally useful, not specific to my code or setup.
Suggested rule title
Magic numbers (or literals) should be replaced with symbolic constants
Rule description
Magic values are numbers or other literals that appear inlne in code without any obvious meaning. This rule should identify such literals and report them to be replaced with a symbolic constant. Simple examples can be seen with error codes or scientific constants:
if e.ErrorCode = 5 then WriteLn('You may not pass!');
would be better as:
if e.ErrorCode = ERROR_ACCES_DENIED then WriteLn('You may not pass!');
Note: not every number is a magic value. I would neither consider 0 nor 1 in this code a magic value:
for (var i := 0 to myList.Count - 1) do
If found a good description of such a rule here (not mine!): https://refactoring.guru/replace-magic-number-with-symbolic-constant
Rationale
Magic values (most often numbers, applies to other literals as well though) make it harder to read, understand and maintain code. By replacing them with a symbolic constant, one gains the benefits of
- a single/reusable point of definition that can be updated when needed
- a meaningful/symbolic name that describes and documents the contents and improves readability
- Dominant language
- Java
- Stars
- 159
- Forks
- 33
- Avg merge
- 4d 17h
- Merged PRs (30d)
- 6
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from integrated-application-development/sonar-delphi
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
enhancement rule triage
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
engine enhancement
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
feature rule
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Support long directive names in the `{$IFOPT}` directiveMay be free again @jgardn3r claimed this 50 days ago, and no pull request is open. Openengine enhancement
integrated-application-development/sonar-delphi#412 · 1 comment · 1 reaction · 1 assignee ·
All issues in integrated-application-development/sonar-delphi
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
beehive-lab/TornadoVM#1151 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
FasterXML/jackson-dataformats-binary#823 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day