Que faites-vous lorsque votre convention de dénomination entre en conflit avec votre langue?

14

D'accord, c'est une de ces petites choses qui m'a toujours dérangé. Je n'abrège généralement pas les identifiants, et la seule fois où j'utilise un identifiant court (par exemple, i) est pour une boucle serrée. Donc ça m'énerve quand je travaille en C ++ et j'ai une variable qui doit être nommée operatorou classet je dois la contourner ou utiliser une abréviation, car elle finit par ressortir. Attention: cela peut m'arriver de manière disproportionnée, car je travaille beaucoup dans la conception de langages de programmation, où les objets de domaine peuvent refléter des concepts dans le langage hôte et provoquer par inadvertance des conflits.

Comment gérez-vous cela? Abréger? ( op) Mal orthographié? ( klass) Autre chose? ( operator_)

naming 
— Jon Purdy
source
7
Mis à part l'espace de noms, nous devrions peut-être envisager de modifier nos conventions de dénomination? Désolé pour l'évidence.
— Chris
1
@Chris: Vous ne pouvez jamais faire confiance à un programmeur pour réaliser l'évidence! (Bien que dans ce cas, je l'ai.)
— Jon Purdy
7
S'il y a une raison d'aimer la $varsyntaxe de PHP , c'est bien celle-ci.
— Joey Adams
3
@Joey Adams: J'ai souri brièvement quand j'ai vu cette question et je me suis souvenu de toutes les questions de PHP bashing flottant autour de SE.
— Chris
3
Évidemment, changez le code source de la langue pour autoriser mes conventions de dénomination. Cela a également l'avantage de "protéger" mon code car il ne s'exécutera / compilera que sur mon interprète / compilateur.
— dietbuddha

Réponses:

21

  1. Acceptez que vous deviez apporter des modifications mineures à votre convention de dénomination, comme l'ajout de majuscules. Il est préférable d'accepter cela dès que possible afin que tout le code suivant soit cohérent.

  2. Pensez à être plus précis. Mots - clés ont tendance à être assez large, donc réduire classjusqu'à demonstrationClasstravaille non seulement autour des questions , mais augmente également la lisibilité.

— Maxpm
source
10

Ce n'est pas quelque chose que j'ai rencontré, mais si je me retrouve dans une telle situation, j'essaierais de le résoudre avec les options suivantes, dans l'ordre.

  1. Essayez de trouver un synonyme.
  2. (en particulier pour les variables) essayez de trouver un préfixe ou un postfix
  3. (en particulier pour les classes) changez la première lettre en majuscule et oubliez la règle de codage selon laquelle les noms ne doivent pas différer uniquement en cas de casse. Cette option, je n'utiliserais probablement que si le conflit est avec un mot-clé.
  4. Utilisez une abréviation.
— Bart van Ingen Schenau
source
1
Je ne vois pas ce qui ne va pas avec les noms différant uniquement au cas où, en particulier dans les listes d'arguments où le paramètre de type const Foo&n'a pas de nom complet raisonnable autre que foo. Certes, il pourrait être préférable de vous donner Fooun nom plus descriptif que foos'il vit dans un corps fonctionnel et sert un objectif moins spécialisé.
— Jon Purdy
@Jon - Je suis d'accord, bien que personnellement, je préfère les préfixes "p_", "l_" et "m_" plutôt que la casse. J'ai adopté cette convention à cause de la question du nom qui ont tous le même nom. La convention que vous utilisez pour traiter cela est largement hors de propos tant que vous l'utilisez de manière cohérente dans un contexte particulier, bien sûr - l'approche variant selon les cas est certainement assez largement utilisée pour que la plupart des développeurs la reconnaissent.
— Steve314
@Jon - ce commentaire se lit comme si j'appliquais sélectivement la convention uniquement lorsque j'ai le même problème de nom, ce qui n'est pas ce que je voulais dire. Le problème de contexte concerne le langage, le projet, etc. Les conventions sont conçues de manière à ce que le problème ne soit pas un problème chaque fois qu'il se produit (ou plutôt ne se produit pas), pour ne pas être appliqué de manière sélective au besoin.
— Steve314
@ Steve314: J'ai compris votre sens dès le premier commentaire. Je sais pas, les affixes comme ça me semblaient toujours un peu trop proches de Systems Hungarian pour mon confort.
— Jon Purdy
@ Jon: Ce n'est pas une règle que j'applique religieusement, mais je trouve qu'il est plus facile de faire des erreurs si deux identifiants ne diffèrent qu'en cas. Certaines de ces erreurs seront repérées par le compilateur, d'autres sont beaucoup plus difficiles à trouver (surtout si les deux identifiants nomment le même genre de chose). Je préfère avoir une règle générale, avec des exceptions au cas par cas, plutôt qu'un livre complet de règles couvrant tous les cas possibles.
— Bart van Ingen Schenau
6

La langue gagne; vous ne pouvez pas déjouer le compilateur (en ignorant les abominations telles que PL / 1 IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF END, mais alors PL / 1 ne vous amènerait pas à poser la question en premier lieu). Fondamentalement, vous devez suivre les règles de la langue et vous devez trouver une alternative aux mots clés de la langue pour votre propre usage - ou trouver une autre langue.

Donc, sauf dans des circonstances très inhabituelles, vous vous adaptez à la langue, et non l'inverse.

— Jonathan Leffler
source
5

Au lieu d'abréger, pourquoi ne pas allonger? Si vous implémentez une construction de classe dans un langage Foo, que diriez-vous d'utiliser FooClass et foo_class? (Modulo quelles que soient vos préférences de boîtier).

— Winston Ewert
source
Souhaitez-vous préfixer "java" sur chaque identifiant que vous utilisez dans le code Java? Et ne mentionnons même pas les problèmes de préfixe "C ++" sur chaque identifiant ...
— Steve314
@ Steve314, vous n'utiliseriez pas le préfixe java dans le code java, vous utiliseriez le préfixe java dans le code c ++ qui implémente un compilateur java. De plus, vous ne l'utiliseriez que si le reste de l'identifiant était un mot-clé.
— Winston Ewert
OK - vous voulez dire un allongement en termes généraux, car en étant plus précis à quoi l'identifiant fait référence aussi. Pour différentes applications, "classe" peut être renommé "class_taught" ou "class_of_animal" ou "classiness_value" ou autre. Je suis d'accord - je viens de trouver l'exemple orienté compilateurs déroutant.
— Steve314
5

Certaines des abréviations que j'ai utilisées pour class, par ordre de fréquence:

  • cls
  • clss
  • clazz
  • theClass
  • aClass

Si je sais quelle classe l' Classinstance représente, je pourrais l'inclure dans le nom de la variable:

  • stringClass = Class.forName("java.lang.String");
— Mike Clark
source
Jamais vu «cls» pour ça auparavant. J'utilise principalement aClass.
— Konstantin Petrukhnov
4

En C et C ++, les mots clés sont tous en minuscules et la langue est sensible à la casse, donc appuyez de temps en temps sur la touche Maj et de nombreux problèmes disparaissent.

Dans Modula 2, les mots clés sont tous en majuscules - mais tant que vos identifiants ont des lettres minuscules, la différence est évidente et les conflits sont impossibles.

De plus, les conventions de nommage absolues doivent dans une certaine mesure refléter les conventions normales du langage que vous utilisez, donc j'écrirais certainement "maClasse" en Java où j'écrirais plus probablement "Ma_Classe" en C ++.

Fondamentalement, vous n'écrivez pas uniquement pour le compilateur, mais ce que les gens trouvent lisible dépend dans une certaine mesure du contexte et des attentes associées.

— Steve314
source
3
Même pour les langues sensibles à la casse, je pense que le fait d'avoir mélangé classet Classnuirait à la lisibilité du code.
— Karmastan
@Karmastan - cela dépend peut-être du temps que vous avez passé à travailler avec des langues et des conventions sensibles à la casse. Personnellement, le "C" supérieur ou inférieur est visuellement très évident - je vois les modèles d'utilisation de cas pour les identificateurs longs plus rapidement que je ne peux les lire.
— Steve314
3

Je ne rencontre pas souvent cela, mais quand je le fais, cela a tendance à être un non-problème parce que j'utilise Delphi et cela vous permet de contourner ce problème en ajoutant un & à l'identifiant. Ainsi, "classe" n'est pas un identifiant valide, mais "& classe" l'est.

— Mason Wheeler
source
Intéressant. J'ai un utilitaire de génération de code qui autorise les littéraux de chaîne partout où un identifiant peut être utilisé. À l'origine, la plupart des identifiants du code généré étaient écrits sous forme de littéraux de chaîne pour éviter le risque de conflits de mots clés avec une DSL croissante (et riche en mots clés). Maintenant, les identifiants sont utilisés pour la plupart des noms (il est surprenant de voir à quel point la source est plus lisible de cette façon), mais les littéraux de chaîne sont toujours disponibles comme solution de rechange. Je pensais que c'était bon pour la génération de code, mais les solutions de contournement des mots clés seraient une mauvaise idée dans un langage à usage général - mais je me trompe peut-être.
— Steve314
2

J'ajouterais une sorte d'espacement de noms au nom de variable. Par exemple, supposons que vous ayez un module nommé utilisateur, je modifierais l'opérateur de nom de variable pour qu'il ressemble à user_operator ou userOperator.

— Pemdas
source
2
il suffit de ne pas utiliser "smooth", "no" ou "my" comme préfixe
— Steven A. Lowe
2
Absolument. Je vote "Jon_Purdys_Carefully_Chosen_Identifier_Prefix_".
— Steve314
1
@Steven: Pire encore, je vois a, anet theutilisé avec une fréquence inquiétante par les élèves débutants CS.
— Jon Purdy
1
@Jon Purdy, ce n'est pas de notre faute! Blâmez le professeur qui a décidé de nommer leur instance de classe People () aPerson.
— Ben L
@Jon: La convention de nommage où je travaille spécifie que les variables locales doivent commencer par en adehors des variables de boucle étroite: /
— Matthieu M.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.