web-dev-qa-db-fra.com

Convention de dénomination: champs finaux (non statiques)

Aujourd'hui, j'ai eu une discussion avec un collègue sur la dénomination des champs final dans les classes Java.

Dans son opinion, les champs final doivent également être considérés comme des constantes car leurs valeurs ne changeront pas après la création de l'instance.

Cela conduirait à la convention de dénomination suivante pour les champs final:

public class Foo {
    private static final String BLA_BLA = "bla";

    private final String BAR_BATZ;

    ...
}

À mon avis, seulement static final les champs doivent être considérés comme des constantes tandis que les champs qui ne sont que final doivent suivre la convention de dénomination camelCase habituelle.

public class Foo {
    private static final String BLA = "bla";

    private final String barBatz;

    ...
}

Maintenant, je suis un peu incertain car il est un programmeur beaucoup plus expérimenté que moi et je suis généralement d'accord avec ses opinions et le considère comme un très bon développeur.

Des commentaires à ce sujet?

javanamingfinal
25
Sascha Wolf

Sun (et maintenant Oracle) a conservé un document intitulé Conventions de code pour le Java . La dernière mise à jour a eu lieu en 1999, mais l'essence du style la ligne guide vit toujours.

Chapitre 9 couvre les conventions de dénomination.

Pour un type d'identifiant de "constantes":

Les noms des variables déclarées constantes de classe et des constantes ANSI doivent être tous en majuscules avec des mots séparés par des traits de soulignement ("_"). (Les constantes ANSI doivent être évitées, pour faciliter le débogage.)

Les exemples donnés:

static final int MIN_WIDTH = 4;

static final int MAX_WIDTH = 999;

static final int GET_THE_CPU = 1;

Dans un document plus récent - son glissé là-dedans. From Variables (The Java Tutorials> Learning the Java Language> Language Basics :

Si le nom que vous choisissez se compose d'un seul mot, épelez ce mot dans toutes les lettres minuscules. S'il se compose de plusieurs mots, mettez en majuscule la première lettre de chaque mot suivant. Les noms gearRatio et currentGear sont de parfaits exemples de cette convention. Si votre variable stocke une valeur constante, telle que static final int NUM_GEARS = 6, La convention change légèrement, mettant en majuscule chaque lettre et séparant les mots suivants par le caractère de soulignement. Par convention, le caractère de soulignement n'est jamais utilisé ailleurs.

De nombreux analyseurs statiques pour Java cherchent à appliquer cela. Par exemple checkstyle applique:

Vérifie que les noms constants sont conformes à un format spécifié par la propriété format. Une constante est un champ statique et final ou un champ d'interface/d'annotation, sauf serialVersionUID et serialPersistentFields. Le format est une expression régulière et par défaut est ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.

Cela se résume vraiment aux conventions de la communauté écrivant le code ... et idéalement le gardant le même.

Les exemples ci-dessus sont donnés en tant que static final Qui sont probablement dérivés des conventions C pour #define - qui, comme C, sont remplacées dans le code lors de la compilation plutôt qu'à l'exécution.

La question qui devrait alors être posée est "est-ce que cela se comporte comme une constante? Ou est-ce comme un champ à écriture unique?" - puis suivre les conventions en conséquence. Le test décisif pour une telle question serait "Si vous étalonniez l'objet, incluriez-vous le champ final?" Si la réponse est qu'il s'agit d'une constante, traitez-la comme telle (et ne la sérialisez pas). D'un autre côté, s'il fait partie de l'état de l'objet qui devrait être sérialisé, ce n'est pas une constante.

Quoi qu'il en soit, il est important de s'en tenir au style de code, qu'il soit juste ou faux. Les problèmes les plus graves surgissent de conventions incohérentes au sein d'un projet plutôt que simplement quelque chose qui choque l'œil. Pensez à obtenir des outils d'analyse statique et à les configurer pour maintenir la cohérence.

20
user40980

BAR_BATZ n'est pas une constante dans cet exemple. Les constructeurs de Foo peuvent lui attribuer différentes valeurs au niveau de l'objet. Par exemple

public class Foo {
    private final String BAR_BATZ;

    Foo() {
       BAR_BATZ = "ascending";
    } 

    Foo(String barBatz) {
       BAR_BATZ = barBatz;
    }
}
5
Kirby