1
votes

Comment éviter l'avertissement de nombre magique lors de l'initialisation d'un champ statique (par exemple BigDecimal)?

J'ai un champ statique

private static final BigDecimal MAX_AMOUNT = BigDecimal.valueOf(299_999L).setScale(4, BigDecimal.ROUND_HALF-EVEN)

Et je reçois un avertissement de CheckStyle que 299_999L est un nombre magique. Comment éviter cela - 299_999 est juste une longue transformation en BigDecimal spécifié .

Je n'ai trouvé dans la documentation de CheckStyle aucune solution appropriée.

MODIFIER : Il sort lorsque je tape par exemple:

private static final BigDecimal MAX_AMOUNT = BigDecimal.valueOf(299_999L);


2 commentaires

Intéressant! Je ne peux pas reproduire ce comportement. Quelle version de Checkstyle utilisez-vous? Pouvez-vous partager la configuration de MagicNumber depuis votre checkstyle.xml ? Selon la documentation , vous ne devriez pas recevoir cet avertissement.


Auch mon mal. Il sort quand je tape BigDecimal.valueOf (299_999L) .setScale (4, BigDecimal.ROUND_HALF-EVEN);


3 Réponses :


0
votes

Vous devez déclarer une constante pour décrire un peu plus ce que signifie cette valeur:

private static final Long MAX_AMOUNT_INITIALIZER = 299_000L;
private static final BigDecimal MAX_AMOUNT = BigDecimal.valueOf(MAX_AMOUNT_INITIALIZER);

Cela semble redondant mais rappelez-vous qu'un nombre magique est tout nombre utilisé le long du code qui ne le fait pas avoir une explication de sa signification. Même si vous avez une constante BigDecimal , votre valeur Long n'est pas interprétée comme une "valeur significative" pour le contexte.


0 commentaires

1
votes

Il est intéressant que vous obteniez cette erreur lors de la déclaration d'un champ statique. Mais peu importe comment vous pouvez ajouter une annotation de suppression d'avertissement,

@SuppressWarnings("checkstyle:magicnumber")


0 commentaires

0
votes

Après votre commentaire de clarification, je peux dire que la raison de l'avertissement est dans le fonctionnement du contrôle MagicNumber . Si le nombre magique potentiel est dans une définition de champ et que ce champ est final , alors il n’est pas marqué tant que tous les jetons parents dans l'AST jusqu'au nœud représentant la définition du champ sont dans une certaine liste.

C'est assez déroutant, et je pense que pour un utilisateur normal, cela semble arbitraire. Mais l'analyse de code statique est souvent une question d'heuristique.

La bonne chose est que vous pouvez influencer ce comportement. Configurez la vérification comme ceci:

<module name="MagicNumber">
    <property name="constantWaiverParentToken"
        value="TYPECAST, METHOD_CALL, EXPR, ARRAY_INIT, UNARY_MINUS, UNARY_PLUS, ELIST, STAR, ASSIGN, PLUS, MINUS, DIV, LITERAL_NEW, DOT"/>
</module>

La valeur de constantWaiverParentToken est le code par défaut plus DOT > ajouté à la fin. Cela permet des expressions plus complexes. Vous avez besoin d'au moins Checkstyle 6.11 pour que cela fonctionne.


1 commentaires

Il convient de noter que constantWaiverParentToken ne prend pas en compte la méthode appelée, donc il masquera les violations où la méthode change la valeur de la constante ou s'il y a plusieurs constantes dans l'appel de méthode.