La variable doit-elle être nommée Id ou ID? [fermé]

126

C'est un peu pédant, mais j'ai vu certaines personnes utiliser Idcomme dans:

private int userId;
public int getUserId();

et d'autres utilisent:

private int userID;
public int getUserID();

L'un de ces noms est-il meilleur que l'autre? Pourquoi? J'ai vu cela se faire de manière très inconsistante dans les grands projets. Si je devais établir une norme à laquelle la plupart des gens seraient familiers? Quelle est la norme conventionnelle?

coding-style naming variables

— Adam
source

40

La cohérence est la chose la plus importante qui compte. Qu'il s'agisse d'une affaire de chameau, de soulignement ou de quoi. Être cohérent.

38

Examinez les API XML de votre langue pour voir comment elles fonctionnent. Classes de noms Java comme SAXParseret DOMException, .NET noms de classes XmlDocument. Sur cette base, je dirais "ID" en Java, "Id" en C #.

— luiscubal

1

Mais les identificateurs majuscules, par convention, sont utilisés en Java pour les champs statiques. Le nom "ID" du champ de base n’est donc pas le meilleur. Et voilà la consistance ...

— Danubian Sailor

8

Voulez-vous nommer les variables EGOet SuperEGO? Je ne le pensais pas. ;)

— kojiro

4

Quoi?! Cohérence? Où est la guerre de rage?! Ça y est, je me nomme ainsi gardien de la flamme de la syntaxe sacrée des chameaux et déclare que le fait de le mettre en majuscule pour les acryonymes est réservé aux noobs. En outre, il est correct de vouloir avoir le rouleau de papier de toilette par le haut, sauf si vous avez des chats qui s'ennuient et font des choses étranges. propriétaires de chat. Je ne sais pas pourquoi je décide de le faire. Bob, le gardien de la flamme sacrée du rouleau de papier toilette, est occupé, je suppose.

— Erik Reppen

56

La règle la plus importante à suivre dans ces cas est la cohérence: faites comme tout le monde.

Par exemple, examinez les API XML de votre langue pour voir comment elles procèdent.

Les classes de noms Java comme SAXParser et DOMException , les classes de noms .NET comme XmlDocument .

Sur cette base, je dirais "ID" en Java, "Id" en C #.

Cependant, j'ai vu que Java EE 6 avait une annotation nommée @Id(voir la documentation ), il semble donc que Java considère "Id" comme un mot normal.

— luiscubal
source

@Id pointe vers un nom de classe d'annotation, pas un nom de variable. Mauvais exemple.

— Jwenting

3

SAXParser pourrait être (et heureusement ne l’est pas) SimpleAPIforXMLParser (ou même SimpleApplicationProgramingInterfaceforExtesibleMarkupLanguageParser). Chaque lettre majuscule commence un mot. Donc, même en Java, il devrait être "Id"

— user470365

2

@jwenting Le problème est de savoir si "id" est considéré comme un mot ou comme deux mots. @Iddit que c'est un seul mot, donc le nom de la variable serait "id".

— luiscubal

Non. SAX est un acronyme, alors que Id ne l’est pas.

— Nalply

8

Vous avez raison d'utiliser Iden C # (et .NET en général), mais pour une raison différente. La règle met en majuscule toutes les lettres d'un acronyme de 2 lettres (par exemple IPAddress) et en majuscule la première lettre d'un acronyme plus long (comme dans l'exemple que XmlDocumentvous avez donné). Mais Idet Oksont les exceptions à cette règle, spécifiquement mentionnées. Pour le mémoire complet, voir la Capitalization Rules for Acronymssection de l' Capitalization Conventionsarticle. Mais même Microsoft enfreint cette règle (par exemple, DbConnectioncontre DBNull)

— Allon Guralnek

110

La cohérence est roi. choisissez l’un ou l’autre, mais faites-le partout.

Cela dit, je préfère la première variante, car elle ne viole pas camelCase (cela signifie que vous devez vous rappeler deux règles de style, pas une seule).

Deux lettres majuscules sont parfois utilisées pour cette raison , mais une carte d'identité n'est en réalité qu'une forme d'identification.

— Robert Harvey
source

18

Pour ma part, je ne voudrais pas si un programme informatique essayait d'accéder à mon identifiant.

— Blrfl

1

userIdOfSender

— Sean McSomething

19

@SeanMcSomething: Ick. SenderUserId

— Robert Harvey

5

Bien que je sois d’accord avec vous, c’est la manière privilégiée d’identifier la confusion: «Dans la conversation quotidienne, nous le disons comme s’il s’agissait d’un acronyme, comme dans« puis-je voir votre identité?

— 500 - Erreur interne du serveur

3

Regardez d'autres acronymes dans l'affaire Camel. Il existe SoapProtocol, pas SOAPProtocol. ID est l'abréviation de document d'identité. Je ne vois donc pas pourquoi il conviendrait de le traiter de manière exceptionnelle dans une affaire de chameaux. Cela dit, je préférerais que l'ID utilisateur soit utilisé de manière cohérente par rapport à l'ID utilisateur et que l'ID utilisateur est utilisé de manière incohérente dans mon programme.

— Neil

76

TL; DR: dans le contexte des bibliothèques de classe .NET, Microsoft vous recommande d'utiliser Id. Ceci est légèrement contre-intuitif, car il s'agit d'un exemple rare d'abréviation autorisée / recommandée (les abréviations sont généralement mal vues).

Si nous parlons de conventions de bibliothèques de classes C # ou .NET, Microsoft dispose de directives de dénomination assez bien définies . Ils sont bien pensés, avec de nombreuses explications sur une variété de problèmes - en fait, chaque développeur devrait prendre un certain temps pour lire l'intégralité de la section des directives de conception .

En ce qui concerne les acronymes , la règle générale est la suivante: pour les acronymes à deux lettres, vous avez tendance à les conserver en majuscules (lorsque le cas Pascal est applicable), par exemple, il IOStreampeut s'agir du nom d'une classe. Pour un acronyme plus long, vous mettez en minuscule le reste de l'acronyme, par exemple XmlDocumentou HtmlParser. Il s’agit en fait d’une règle généralement non ambiguë (il n’ya pas de confusion quant à la fin et à la fin du mot suivant, sauf si vous enchaînez des acronymes à deux lettres), et vous vous y habituerez très rapidement.

Alors, est-ce un identifiant ou un identifiant? Eh bien, selon Microsoft, ce n'est peut-être pas ce que vous pensez:

Les sigles diffèrent des abréviations en ce qu'une abréviation raccourcit un seul mot. Par exemple, ID est une abréviation d’identificateur . En général, les noms de bibliothèque ne doivent pas utiliser d’abréviations.

Les deux abréviations pouvant être utilisées dans les identificateurs sont ID et OK. Dans les identifiants en cascade Pascal, ils doivent apparaître sous la forme Id et Ok. S'ils sont utilisés en tant que premier mot d'un identifiant avec une casse de chameau, ils doivent apparaître respectivement avec id et ok.

De manière anecdotique, je ne sais pas vraiment quand cette distinction a commencé à apparaître dans les directives, mais il y a quelques années (environ 3,0 / 3,5), la tendance générale en matière de nommage dans les bibliothèques de classes est passée de ID à Id.

— Daniel B
source

1

C'est la ligne directrice que je suis habituellement. Puisque id est une abréviation et non un acronyme, je préfère toujours utiliser 'Id'.

— Toby

J'utilise ID car alors il enfreint la convention et se distingue comme étant unique, et j'aime l'ironie de cela :)

— RhysW

Je pense que Microsoft a tort. ID est un initialisme pour Document d'identité, ce n'est pas une abréviation pour identité. (Pédantiquement, les acronymes sont prononçables.)

— Tom Hawtin - tackline

@ TomHawtin-tackline Vous soulignez un point intéressant, même si je suppose que cela dépend du contexte. Quelque chose comme une propriété IDNumber sur un objet Personne aurait beaucoup de sens, mais pour VehicleId, lire comme "Document d'identité du véhicule" par opposition à "Identificateur du véhicule"? Dans les contextes de programmation, identifiant est un mot assez courant pour tout ce qui identifie de manière unique une instance, et je dirais qu'il est plus applicable ici.

— Daniel B

@DanielB Dans les langages informatiques, même SQL, "identifiant" désigne généralement un nom, tel que le nom d'une colonne. En règle générale, il est abrégé en "ident". Véhicule est un exemple intéressant car il existe des schémas VIN (numéros d'identification de véhicule) établis. Dans un contexte de programmation typique, le "document" d'une entité est un nombre (il peut même s'agir d'une capacité infalsifiable).

— Tom Hawtin - tackline

15

J'ai lu une très bonne explication dans le document de certaines conventions de codage. CamelCase doit toujours être utilisé pour les acronymes et les abréviations, car il est plus facile de distinguer les limites des mots (comparer XmlIdWriteraux XMLIDWriter).

— Gilden
source

12

Voici une idée encore meilleure pour distinguer les limites de mots: les limites de mots réelles! xml_id_writer.

— Kaz

4

@ Kaz Eh bien, duh! Cependant, CamelCase est utilisé traditionnellement dans certaines langues et il serait plutôt déplacé d'utiliser des traits de soulignement dans de telles situations. La cohérence est roi, comme mentionné précédemment.

— Gilden

1

L'utilisation de CamelCase simplement parce que les bibliothèques principales de certaines langues l'utilisent, ce n'est pas la cohérence, mais plutôt la conformité.

— Kaz

3

@Kaz: Vous avez de plus grandes batailles à mener dans votre boutique que les conventions de code.

— Robert Harvey

2

Comme nous pouvons le voir dans la fonction par défaut de JavaScript getElementById (); Id est écrit dans l'affaire Camel ...

Utilisez 'id' si vous utilisez un trait de soulignement. Exemple: id_utilisateur

Utilisez 'Id' si vous nommez une var sans trait de soulignement pour différencier les différents mots. Exemple: userId

Si c'est une seule variable mot, il doit être en minuscule, si plusieurs mots var, utilisez une casse inférieure. Exemple: thisIsExample

Mais je ne recommanderais pas fortement «ID» dans CAPS car nous utilisons généralement des majuscules pour définir CONSTANTS.

— Sukrit Gupta
source

Dans votre troisième paragraphe, votre exemple ne semble pas correspondre à votre texte?

— Ruakh

@ruakh thanx .. Rectified ..

— Sukrit Gupta

0

Tout d'abord, évitez les abréviations.

Deuxièmement, si l’abréviation est super bien connue, je recommande d’utiliser un étui camel.

C'est parce que vous n'avez pas besoin de considérer le sens de cela. juste traiter comme un mot normal

— Sungguk Lim
source