ID, id ou Id? [fermé]
J'utilise camelCase dans Mes noms de champs de code et de base de données, etc., mais avec les champs qui ont Id à la fin, il finit toujours par être difficile à lire. Par exemple, itemId, teacherId, unitId, etc. Dans ces cas, je considère briser la convention et écrire itemID, teacherID, or unitID juste pour améliorer la lisibilité.
Que faites-vous et quelle est la meilleure pratique générale pour traiter ce problème?
20 réponses
Je fais ce que je ressens. En général, votre meilleure pratique consiste à pécher en faveur de la lisibilité par rapport à la conformité à une norme abstraite.
Soyez cohérent.
Id est une abréviation, pas un acronyme, donc je le casse " Id."UI est un acronyme,et les acronymes-courts, de toute façon-sont capitalisés:" UI."
Voici un échantillon de ce que je fais.
id
userId
getUserId
La clé est d'être cohérent.
Je préfère en fait "ID". Mais, comme tout le monde le dit, la cohérence est la chose la plus importante.
Steve
Id, comme pour L'identifiant. Les conventions de nommage suggérées par Microsoft indiquent que c'est la pratique recommandée et la compilation avec l'analyse de code le soutiendra. Vous utiliseriez ID s'il représentait deux mots commençant respectivement par I et D et vous n'êtes vraiment pas censé utiliser des noms commençant par des lettres minuscules mais dans des paramètres.
Peu importe, tant que vous êtes cohérent tout au long de votre programme .
Cela étant dit, j'irais avec "Id".
J'utilise camelcase, aussi et je l'utilise aussi si le nom se termine par Id.
Id
C'est ma réponse subjective à la question subjective.
J'ai marqué ceci comme CW cependant.
J'utilise des traits de soulignement dans tous mes noms de table, donc user_id. Même si id est autonome, tout est en minuscules.
C'est prononcé "Eye dee", pas "id comme dans id, ego et surmoi", donc ID, pas Id. C'est mon vote, de toute façon. Le fait que ce soit une abréviation, plutôt qu'un acronyme est hors de propos, en raison de la façon dont il est prononcé. Il est prononcé comme s'il s'agissait d'un acronyme, donc il peut aussi bien être tapé de cette façon. Oh, et camel case est la pire idée de l'histoire de l'informatique.:)
Je pense que la lisibilité est de la plus haute importance, et devrait remplacer votre convention si elle va le rendre beaucoup plus facile à lire. Je pense que les inconvénients l'emportent sur les avantages de s'en tenir à vos armes / convention si vous ne pouvez pas le lire facilement (autant que nous, les programmeurs, détestons casser les conventions et les protocoles).
Dans Machine SUIF, Mike Smith et Glenn Hollowayappliquent rigidement la convention de cas selon laquelle une lettre majuscule marque un nouveau mot. Donc, même si CPS est un acronyme, c'est transformToCps et non transformToCPS. J'ai trouvé qu'à long terme, leur méthode fonctionne mieux que ce que nous avons fait dans Quick C--, où nous avons généralement fait toutes les majuscules pour des cas comme ID et CPS.
FxCop / Code Analysis marquera ID comme étant une mauvaise abréviation, donc si vous voulez éviter de désactiver une règle, vous pouvez vous conformer et utiliser Id pour cette raison. Mais encore une fois, ce n'est pas vraiment d'importance, tant que vous êtes cohérent, comme cela a été souligné par d'autres.
Tout ce que vous êtes à l'aise avec tant que vous restez cohérent dans vos propres programmes. (Si vous travaillez en équipe, vous devez suivre la règle de l'équipe ou en mettre en place).
Un point qui n'a pas été mentionné est l'importance d'obtenir une bonne police. Cela fera des merveilles pour la lisibilité de votre programme et il se pourrait que votre problème de convention soit en partie un problème de police:
Si vous ne pouvez pas facilement distinguer Id de ld (Id and ld), Vous devriez changer la police et peut-être que la taille de la police aussi. Personnellement, J'aime Consolas.
Je suis d'accord avec les autres réponses que la chose la plus importante est d'être cohérent.
J'ajouterais que, s'il n'y a pas de norme établie pour votre base de code particulière, vous devriez suivre les conventions définies par votre langue ou votre plate-forme. En Java, les acronymes et autres mots en majuscules ne sont pas capitalisés pour les identificateurs:
id
url
getId()
setUrlParameters()
Dans Objective-C, c'est le contraire. Vous pouvez avoir une variable "id" Ou "url" en minuscules, mais vous avez également des classes telles que:
NSURL
NSURLRequest
Donc dans Obj - C je choisirais un nom de méthode comme:
setURLParameters:
ID dans les colonnes de la base de données et les propriétés de l'objet. id dans les paramètres:
this.ID == id
Je préfère utiliser Id et dans notre société, la norme est également Id sur ID. Je ne pense pas qu'il y ait un problème en utilisant ID si vous le trouvez plus facile à lire. Le compilateur s'en fout:) j'utilise la même convention dans mes colonnes d'Id de schéma.
Différentes langues ont des directives différentes. Pour. NET, vous pouvez lire Framework Design Guidelines: Conventions, idiomes et Patterns pour les bibliothèques. net réutilisables. Pour Java, vous pouvez lire Conventions de Code pour le langage de programmation Java .
"Id" est ambigu. Fait-elle partie du "moi" / "surmoi" modèle de la psyché humaine? Probablement pas: vous essayez probablement d'abréger un mot, comme "identité" ou "Identification" ou "identifiant".
Débarrassez-vous de l'ambiguïté (et de la question de casse) en décidant de ce que vous voulez dire et ensuite n'abrégez pas .