Noms de cas de chameaux: quelle sévérité?

Question

Quel est le sentiment sur la rigueur avec laquelle on devrait appliquer le chameau aux variables.

Je pense en particulier aux variables telles que les identificateurs dont les noms contiendront un ID. Utilisez-vous thingID , ou le plus correct thingId ? Le second me semble toujours faux.

Answer 1

Vous pourriez peut-être suivre les lignes directrices que MS a écrit:

• Lorsque vous utilisez une abréviation ou d'un sigle de 2 caractères, de les mettre tous en majuscules
• Lorsque le sigle est plus de 2 char, utilisez un capital pour le premier caractère

Lors de l'utilisation d'acronymes, de l'utilisation Pascal cas ou à dos de chameau cas pour les acronymes, plus de deux caractères. Par exemple, l'utilisation HtmlButton ou htmlButton. Cependant, vous devrait tirer profit des acronymes qui composé de seulement deux personnages, tels en tant que Système.IO au lieu de Système.Io. Faire ne pas utiliser d'abréviations dans les identificateurs ou les noms de paramètres. Si vous devez utiliser les abréviations, l'utilisation de chameau cas pour abréviations qui se composent de plus de deux personnages, même si ce contredit l'abréviation standard de la parole.

Answer 2

Si vous utilisez quelque chose comme FXCop, ID sera signalé et ID sera recommandé. Parce que Id est une abréviation et non un acronyme.

Cet article explique pourquoi: http://weblogs.asp.net/AndrewSeven/archive/2004/08/12/213440.aspx

Je reste avec Id maintenant, pour garder FXCop heureux…

À moins que je ne sois déjà sur un projet utilisant un identifiant, dans ce cas, la cohérence est une meilleure solution.

Answer 3

Vous avez deux objectifs opposés:

• Vous voulez le rendre facile à lire des noms longs
• Vous voulez faire, il est facile de reconnaître les acronymes

La première règle tient compte du fait que la plupart des identificateurs dans les programmes de plus d'une parole et thisisseveralwords prend trop de temps à analyser et il pourrait être carrément maladroit comme dans "pimp" ou "pImp", "childmolestring" vs "childMoleString".

D'autre part, nous avons l'habitude de lire de la RAM, le CPU, ID, DB, IBM qui conduirait à IBMDB2DBConnector au lieu de IbmDb2DbConnector - les deux sont moches parce que nous ne sommes pas habitués à lire des caractères de mettre des motifs. Nos cerveaux ne pas voir I-B-M, ils voient >IBM< (comme si c'était une image au lieu de trois caractères).

Notez que la règle n ° 2 est en fait une spécialisation de la règle n ° 1: le but ultime est de rendre le code lisible. C'est assez dur à comprendre un algorithme inconnu si vous n'êtes pas arraché de votre concentration tout le temps par d'étranges noms.

Ma solution est d'essayer d'éviter les acronymes pour résoudre la question 2. Ainsi, au lieu de "getRAM()" comment parler de "getMemory()" ou mieux "getFreeMemory()"? DB est court mais c'est vraiment une base de données et les Ide modernes, c'est juste un Ctrl+Espace.

Answer 4

La cohérence est le nom du jeu - tenez-vous en à un ensemble de règles, mais celui que vous choisissez ne me semble pas important.

Answer 5

Je l'applique toujours strictement, par souci de cohérence et pour faciliter la lecture. De cette façon, il est également possible de manipuler automatiquement les noms de manière significative.

Pour moi, thingID ne semble pas être correct et getRAMUsage est horrible.