Puisque le langage principal est Java, un résumé personnel de ce qui me préoccupe particulièrement en Java L'interface et la conception ne sont pas mentionnées dans cet article car les détails sont importants.

point

La portée de la variable est-elle le minimum requis?
Le nom de la variable est-il approprié pour la portée?
La variable est-elle immuable?

La portée de la variable est-elle le minimum requis?

Plus la portée est large, plus la variable a de rôle. Cela facilite également l'intégration de bogues tels que l'utilisation et les modifications à des moments inattendus. Je veux garder la portée au minimum nécessaire.

Supposons que vous ayez une méthode de recherche qui interroge le nom à partir d'un tableau d'ID (int).

        String name;
        for (int id : identities) {
            name = find(id);
            //Quelque chose à voir avec le nom
        }

Dans cet exemple de code, la variable name est définie en dehors de la boucle, mais si name n'est utilisé qu'à l'intérieur de la boucle, sa définition à l'intérieur de la boucle réduit la portée.

        for (int id : identities) {
            final String name = find(id);
            //Quelque chose à voir avec le nom
        }

Le nom de la variable est-il approprié pour la portée?

Bien que cela affecte la portée mentionnée ci-dessus, la dénomination des noms de variable et des noms de méthode doit être plus stricte en fonction de la portée. À l'inverse, un champ d'application plus restreint élimine le besoin de rigueur.

Les compteurs de boucle tels que ʻint isont des cas extrêmement courts, mais les variables utilisées dans 2-3 lignes peuvent être de simples noms de variables tels quename et ʻage. D'autre part, les constantes doivent être strictes en fonction du domaine. Par exemple, public static final String DEFAULT_USER_NAME_VALUE =" Anonymous ";. S'il y a un type dans ʻUSER`, la constante augmentera de ce montant, et le nom de la variable devra également être plus strict, ce qui l'allongera.

Si vous voulez utiliser une variable qui signifie un nom à l'intérieur ou à l'extérieur de la boucle, vous devrez faire quelque chose comme ʻuserName ʻadminUserName au lieu d'un nom comme name et name2.

Est-ce immuable?

Les variables peuvent être immuables, sauf pour certaines, comme les compteurs. Dans le cas de variables mutables, des changements et un écrasement d'espace de noms peuvent se produire à des moments inattendus. Certains IDE, comme IntelliJ, même les variables locales sont définies en final lorsque la variable est créée. Cependant, sachez que le contenu de Map et List peut être réécrit même si les variables elles-mêmes sont définitives. Dans le cas de Java, il est souhaitable de renvoyer une copie profonde ou ʻUnmodifiableList avant de renvoyer la méthode qui renvoie la liste finale privée` qui est tenue comme variable d'instance.

    private final List<String> nameList = new ArrayList<>();

    public List<String> getNameList() {
        return nameList;
    }

Je voudrais envisager de le remplacer par ce qui suit.

    private final List<String> nameList = new ArrayList<>();

    public List<String> getNameList() {
        return Collections.unmodifiableList(nameList);
    }

Les constantes primitives peuvent-elles être utilisées?

Je pense qu'il existe de nombreux cas où des constantes String et int (mais pas des primitives) sont utilisées, mais j'aimerais envisager de les remplacer par des types d'énumération et des classes qui les représentent. Par exemple, supposons qu'il y ait un processus d'écriture de données dans un fichier et que les constantes suivantes soient préparées comme mode d'écriture.

    /**
     *Mode addendum
     */
    public static final String WRITE_MODE_APPEND = "append";

    /**
     *Mode d'écrasement
     */
    public static final String WRITE_MODE_OVERWRITE = "overwrite";

    /**
     *Nouveau mode (erreur s'il y a un fichier)
     */
    public static final String WRITE_MODE_NEW = "new";

Une méthode d'écriture utilisant ce mode aurait la signature suivante:

public void write(String data, String mode)

Le premier et le deuxième arguments sont tous les deux «String» et il est difficile de distinguer sans vérifier le nom de l'argument. De plus, si mode est une chaîne qui n'est pas prise en charge à cause de String, il sera nécessaire de la prendre en compte.

Par exemple, en utilisant un type d'énumération ou une classe Mode, des erreurs telles que la transmission des données d'origine comme deuxième argument ne se produiront pas.

    enum WriteMode {
        /**
         *Mode addendum
         */
        APPEND,
        /**
         *Mode d'écrasement
         */
        OVERWRITE,
        /**
         *Nouveau mode
         */
        NEW;
    }

Dans ce cas, la signature ressemblerait à ceci:

public void write(String data, WriteMode mode)

Danger de "Eh bien, pour le moment"

C'est une évidence quand vous regardez cela seul, mais lorsque vous codez pendant la vérification, il y a toujours des codes qui disent "Eh bien, pour le moment", ou un tel code est inclus en raison de l'omission de refactoring. Je veux être prudent avec ma propre prudence car cela pourrait finir.