[typescript:S109]: MagicNumbers : Add Authorized numbers parameter (like [java:S109])

SonarQube Writing rules
, ,
1
  • Version SonarQube 9.9, with SonarJS (TypeScript)
  • Deployment : Docker
  • Goal : Customise rule typescript:S109 with Authorized numbers parameter (like java:S109)

It would be great if the typescript rule S109 have the same customisation as the corresponding Java rule (java:S109).
The current rule have only 3 hardcoded values (-1,0,1) without the ability to change the values (like java:S109).

Java : https://github.com/SonarSource/sonar-java/blob/4494016e28912dc33a279e5c1f2a8d6fe029c56a/java-checks/src/main/java/org/sonar/java/checks/MagicNumberCheck.java
TS/JS : https://github.com/SonarSource/SonarJS/blob/622c9ef5a959c347e649b814e8ecdd6b191bb2d5/sonar-plugin/javascript-checks/src/main/java/org/sonar/javascript/checks/NoMagicNumbersCheck.java

Is it possible to add a parameter on the typescript:S109 rule in order to customise it ?

Thanks

3

Hi @xavier,

What do you have in mind? Do you have an example of numbers you wouldn’t want to be picked up by this rule? Or any particular reason to want to configure this?

FYI we are currently working on some improvements to this rule: Improve S109 (`no-magic-numbers`) · Issue #4004 · SonarSource/SonarJS · GitHub

Gab

6

Here are some use cases:

Simple time formulas: 24 (hours), 60 (minutes, seconds)
Simple algorithms using Random/Hash: Powers of 2: 2, 4, 8, 16, 1024
Simple conversions: Powers of 10: 10, 100, 1000

Having additional authorized numbers permits to define a good trade-off in the reported issues between real bad practices and over-pedantic reports.

1 Like
7

Thanks for the examples Xavier.

We try hard to avoid configuration to keep things simple. Our view is that we rather try to find heuristics for the most common cases and accept the remaining ones as exceptions.

Do you think it would be fair to say that besides your examples and the ones in the ticket, the numbers would be mostly exceptions (rare occasions)?

My reasoning is that if the number has a specific meaning in the project, enough to motivate one to modify a rule, then it should be named in the code, and likely be defined in a single place. For exceptions, we have the “Won’t fix” action on issues.

Do you think that’s fair? Maybe I’m missing something.