Utilisez-vous des conventions particulières pour nommer des variables complémentaires?

Question

Je me trouve souvent en train de chercher de bons noms pour des paires de variables complémentaires; où deux variables désignent des concepts opposés, deux participants à une sorte de duologue, et ainsi de suite.

Cela pourrait être mieux expliqué par un contre-exemple: je gère une application qui imprime deux graphiques dans le cadre d'une publicité imprimée. Ils sont stockés dans la base de données sous les noms TopLogo et LowerLogo , que je dois arrêter et vérifier à chaque fois que je les utilise car je m'attends à top pour compléter bas , et bas doit compléter haut .

Il y a des exemples évidents qui, je pense, fonctionnent bien:

client / serveur
source / target pour copier / déplacer des données ou des fichiers d'une variable à une autre

minimum / maximum

mais il y a des concepts qui ne se prêtent pas à de tels systèmes de nommage. Par exemple, lorsque vous parcourez des enregistrements, «dernier» signifie-t-il «final» ou «précédent»? J'ai récemment vu un code qui utilisait firstPage , previousPage , nextPage et finalPage pour éviter l'ambiguïté lastPage complètement, ce que je pensais être très battu, d’où cette question.

Avez-vous des paires de noms de variables particulièrement soignées que vous souhaiteriez partager avec nous? (Les points bonus s’ils ont la même longueur, ce qui rend le code plus net dans les polices à espacement fixe.)

Answer 1

Comme pour toutes les conventions de style de code, la cohérence est ce que vous devez rechercher.

Je voudrais que l’équipe de développement s’entende sur "standard". des paires de préfixes pour des scénarios courants tels que " source / destination " ou "de / à" et ensuite rester avec eux pour tout le projet. Tant que chaque développeur est conscient de la signification d'un préfixe particulier dans la base de code, il est plus facile d'éviter les malentendus.

Les exceptions à la règle doivent être clarifiées dans la documentation si la variable fait partie d'une API publique, ou dans des commentaires dans le code, si sa visibilité est limitée à une seule classe ou méthode.

Answer 2

Dans mes bases de données, vous trouverez de nombreuses tables temporelles à états valides ("historique") contenant une paire de colonnes nommées date_début et date_fin . Pas de bonus pour moi, donc, parce que je préfère utiliser la "fin" couramment utilisée que d'essayer de trouver une alternative intuitive avec le même nombre de caractères que le mot "commencer".

J'ai tendance à préférer ces termes génériques même lorsque des termes plus spécifiques au contexte peuvent être viables, par exemple. préférer employee_start_date à employee_hire_date (que se passe-t-il si leur emploi a débuté pour une raison autre que le fait d’avoir officiellement embauché, par exemple, leur entreprise a fait l’objet d’une acquisition)? Cela dit, je préférerais date_naissance_personne à date_départ_personne :)

Answer 3

Bien que l’on essaie d’être cohérent sur le plan sémantique dans des cas évidents - par exemple, le maximum va avec le minimum, et non "le plus bas" - dans le code OO bien structuré (ce qui n'est pas tout le code, je sais), le problème disparaît avec un bon IDE. Les classes sont courtes, les méthodes sont courtes et les variables peu nombreuses dans chaque méthode. Donc, peu importe ce que vous appelez les paires de variables tant qu'elles sont claires. Votre code n'a peut-être pas l'air professionnel, mais la qualité réelle réside dans le code et non dans l'apparence de votre code.

Le problème disparaît davantage s'il existe de bons JavaDoc ou quel que soit le système de documentation, et si les bons noms de classe qui les accompagnent. Par exemple, si vous avez une instance d'une classe Connection et qu'elle possède une méthode appelée setDestination , ce n'est pas grave, mais si vous savez que setDestination prend un paramètre appelé < code> destination et de la classe Serveur , vous êtes cool ... même si vous préférez l'appeler cible , aimHere , placeToSendTheData ou quel que soit (et les noms correspondants, source , comingFromHere et placeToGetTheDataFrom ). De plus, le système de documentation indique à quoi sert la chose , ce qui n'a pas de prix.

Cette prochaine chose peut paraître stupide et je suis sûr que je serai critiqué ici sur StackOverflow, mais les noms de variables uniques à consonance non professionnelle présentent un avantage considérable: je sais que mes variables ont des noms tels que placeWeWantTheDataToGo (et l'IDE prend soin de le taper), mais le "grave" " les gars qui font le JDK n’auraient jamais utiliser des noms aussi stupides. Je sais donc tout de suite que la variable est une des miennes. Incidemment, lorsque je travaillais avec des développeurs en Espagne et en Italie, ils écrivaient du code avec des noms de variables espagnols (pas toujours, mais généralement). Cela a le même effet: nous pouvons rapidement constater que la classe Conexion est la nôtre, mais pas la classe Connection .

[De plus, au lieu de taper vos noms de variables, assignez-leur une chaîne constante quelque part dans votre code et utilisez-la. Par conséquent, s'ils l'appellent lower ou downer au lieu de low, vous pouvez continuer.]

Answer 4

Oui, j'essaie de nommer systématiquement des ensembles complémentaires de variables pour que la symétrie soit claire. Ce n'est pas toujours facile; parfois, même pas possible. Eh bien, ce n’est pas possible d’utiliser les règles que je me fixe - ce qui signifie que j’essaie généralement d’avoir les noms de la même longueur. Les exemples "haut" et "bas" me conduiraient mal (en supposant que je ne le suis pas déjà, ce qui est loin d'être certain); J'utiliserais probablement 'supérieur' et 'inférieur' car celles-ci ont la même longueur; "haut" et "bas" me frustreraient aussi à cause de la différence de longueur.