Conventions de dénomination: camelCase contre underscore_case? quen pensez-vous? [fermé]

Je conviens que cela dépend dans une certaine mesure de la langue que vous utilisez; le code a tendance à être plus net lorsque les noms de vos symboles suivent le même format regimen comme les bibliothèques intégrées et stock du langage.

Mais là où il y a un choix, je préfère les traits de soulignement au cas camel, pour une raison simple: je trouve ce style plus facile à lire. un exemple: lequel trouvez-vous le plus lisible? Ceci:

aRatherLongSymbolName 

ou ceci:

a_rather_long_symbol_name 

Je trouve la version de soulignement beaucoup plus facile lire. Mon cerveau peut ignorer les traits de soulignement beaucoup plus facilement quil ne peut détecter les limites minuscules / majuscules dans le cas du chameau, en particulier lorsque les limites sont entre des glyphes qui ressemblent à dautres glyphes du cas contraire, ou des chiffres (I/l, O/0, t/I, etc.). Par exemple, cette variable booléenne stocke une valeur indiquant si un Igloo a été construit avec les autorisations de planification appropriées (sans aucun doute un cas dutilisation courant pour nous tous):

isIllicitIgloo 

Je trouve cette version beaucoup plus facile à lire:

is_illicit_igloo 

Peut-être même pire quun nom de symbole difficile à lire est un nom de symbole facile à lire. Les bons noms de symboles sont auto-documentés, ce qui signifie pour moi que vous devriez être capable de les lire et de comprendre leur signification en un coup dœil. (Je suis sûr que nous lisons tous des impressions de code au lit pour le plaisir, mais parfois nous grognons à la hâte aussi.) Je trouve souvent avec les noms de symboles de cas de chameau quil est facile de mal les lire et davoir une mauvaise impression de la sémantique dun symbole.

Commentaires

• Un problème avec les traits de soulignement: la convivialité. Pour la plupart des claviers (européens), taper le signe de soulignement nécessite de maintenir Appuyez sur la touche SHIFT. Vous devez également le faire pour camelCase, mais je peux confortablement maintenir SHIFT avec le petit doigt et taper nimporte quelle lettre – mais comme la touche de soulignement se trouve juste à côté de la touche SHIFT, appuyer sur les deux en même temps est plutôt gênant et interrompt le flux de saisie.
• Pour le premier, jai trouvé camelCase plus facile à lire – bien que ce dernier soit évidemment différent.
• Cela dépend en effet de ce que vous ' y est habitué. Je trouve que les camelCases sont plus faciles à lire, et en plus, ils ' sont plus courts que les noms de soulignement équivalents.
• Je déteste taper des traits de soulignement.
• Le point " utilisabilité " nest pas pertinent pour cela. Le code est généralement écrit une seule fois par une seule personne, mais disons ' dans l’ordre de 1 à 10 fois, ce qui représente une édition et une programmation potentielle par paires. Mais le code est généralement lu des dizaines / centaines / milliers de fois par une ou potentiellement plusieurs personnes. Ainsi, rendre le code facile à lire est plusieurs grandeurs plus important que davoir un code facile à écrire.

Je pense que vous devriez utiliser la convention de dénomination adoptée par votre plate-forme. underscore_case aura lair bizarre dans le code C #, comme camelCase en Ruby =)

Commentaires

• La cohérence est une clé. Que vous soyez daccord ou non avec la convention locale, vous faciliterez votre temps (et tout le monde ' s) en étant cohérent. (À moins que la convention locale ne soit elle-même incohérente.) De plus, la lisibilité est principalement un faux argument: lisez suffisamment de code si vous ' découvrirez quil y a peu de différence, sauf si vous décidez quil est illisible.
• Entièrement daccord. Je pense juste quil vaut mieux utiliser des conventions de plate-forme plutôt que des conventions personnalisées, car par exemple les nouveaux membres de léquipe se sentiront plus à laise avec.
• Mais malheur à ceux dentre nous qui travaillent sur deux plates-formes avec deux conventions , là où certains préfèrent et dautres préfèrent lautre!
• Si la plate-forme a 2 conventions, je ' demande à tous les membres de léquipe de voter pour la convention avec laquelle ils sont à laise =)

Honnêtement, cela na pas vraiment dimportance tant que tout le monde dans léquipe utilise le même schéma. Il y a de fortes chances que lun ou lautre vous soit plus naturel, bien que la vraie importance soit la lisibilité du code à long terme et quil soit alors crucial que tout le monde adhère aux mêmes règles de dénomination.

Commentaires

• vous avez tout à fait raison, cependant je ' m essayant de connaître lopinion des gens sur la sorcière serait mieux dutiliser (laissez ' dit pour toute léquipe), et pourquoi … alors que je comprends que certaines personnes peuvent être simplement habituées à une convention ou dautres sont plus naturelles avec lautre.

Basé sur une réponse la réponse de John Isaacks:

« honnêtement le code est plus facile à lire » Opinion ou fait?

Jai décidé de faire quelques recherches et jai trouvé cet article . Que dit la science sur le sujet?

1. Lenveloppe de chameau a une plus grande probabilité dexactitude que les traits de soulignement. (les probabilités sont 51,5% plus élevées)
2. En moyenne, la caisse de chameau a pris 0,42 seconde de plus , ce qui est 13,5% de plus.
3. La formation na pas dimpact statistiquement significatif sur la manière dont le style influence lexactitude.
4. Ceux avec plus de formation étaient plus rapides sur les identifiants dans le style camel case.
5. Sentraîner dans un style, a un impact négatif sur le temps de recherche pour les autres styles.

Dans mon article de blog sur le sujet, je passe en revue le article scientifique, et faites la conclusion suivante.

Seule la lenteur du cas du chameau ( 2) est vraiment pertinent pour la programmation, rejetant les autres points comme non pertinents en raison des IDE modernes et de la majorité des utilisateurs de camelCase dans létude. La discussion (avec un sondage) peut être trouvée sur le billet du blog.

Je suis curieux de savoir comment cet article pourrait changer notre opinion. 🙂

Commentaires

• Bien sûr, vous ignorez tous les autres points en raison de votre préférence pour les traits de soulignement et les autres points ne ' ne vous aident pas …
• @Charles: Oui et non, à mon humble avis, je fais de bons arguments pour expliquer pourquoi ils sont rejetables, et certains dentre eux sont même considérés comme problématiques par le journal lui-même. A document de suivi examine certains des problèmes de cet article , et les résultats sont favorables à des soulignements.

Copiez les plus intelligents

Dans le cas des langages de programmation, copier le style du développeur du langage.

Par exemple, je code C exactement comme on le fait en K & R.

Ensuite quand quelquun essaie de commencer un codage ennuyeux conversation de style, je peux leur dire « en parler avec Dennis Ritche et me faire savoir ce quil dit. »

Commentaires

• Loriginal nest pas toujours le meilleur. Il y a beaucoup de mauvaises pratiques dans le livre évangélique K & R sur C. Avant que cela ne commence une guerre des flammes … lisez quelques-unes des recommandations MISRA.
• Noubliez pas ', K & R a été écrit alors quil ny avait pas dinterface utilisateur IDE. La plupart des travaux ont été effectués sur des terminaux de caractères 80×25, donc l’espace sur l’écran était limité, car if (...) { a sauvé une ligne! De nos jours, il y a ' s plus d’espace sur l’écran – K & R serait-il différent s’il était écrit aujourd’hui avec des IDE d’interface graphique haute résolution et plusieurs moniteurs mises en place?
• Ouais, mais quand quelquun dit quil code C comme K & R, il obtient des accessoires pour être de la vieille école.
• @quickly_now , parlez-en à Dennis Ritchie et faites-moi savoir ce quil dit!
• Jadopte beaucoup de formatage de MS: _internalToClassOnly, accessibleByGetter, PublicVariable.

En général, je préfère camelCase. Cependant, cest parce que la plupart de ma carrière, jai travaillé dans des langages et des environnements où les guides de style recommandent normalement camelCase. (Java, ECMAScript, C ++). Vous, en tant que personne PHP, êtes susceptible davoir la préférence opposée.

Cela dit, lorsque vous dépassez troisOrFourWords, ou si vous utilisez des initialismes comme XmlForExample, cela cesse dêtre si lisible.

Cest pourquoi emacs nous propose le mode lunettes.

Commentaires

• +1 pour mavoir fait découvrir le mode lunettes! Je viens de le tester sur un fichier de code qui utilise camelCase, et jai remarqué à quel point il a immédiatement commencé à mieux paraître (assemblage avec des tas détiquettes dans camelCase).
• Ok, quest-ce que le mode lunettes?
• gnu.org/software/emacs/ manual / html_node / emacs / Glasses.html

camelCase

Cest lun des rares endroits où je choisirai toujours la » capacité de type « plutôt que la lisibilité. CamelCase est juste plus facile à taper, et être plus gentil avec mes doigts lemporte sur un léger gain de lisibilité pour moi.

en supposant bien sûr que le projet ne repose pas sur une base de code existante avec un standard différent.

Commentaires

• Je ne suis ' daccord avec cela, vous nécrivez le code quune seule fois, mais vous devez le lire plusieurs fois par la suite

Cest une question intéressante, jy ai réfléchi plusieurs fois. Mais il ny a pas de réponse définitive, je pense.

Suivant les conventions « culturelles », cest un bon choix. «Culturel» dans ce cas signifie les conventions mises en place dans léquipe / lentreprise et elles portent essentiellement les conventions de langue / plate-forme. Cela aide les autres à lire / utiliser votre code facilement et ne nécessite pas d’efforts et de temps supplémentaires pour comprendre votre code.

Parfois, il est intéressant de briser les notations acceptées. Un de mes petits projets (sur Python) Jai utilisé underscored_names pour les fonctions utilitaires / méthodes « protected » et methodNames de style Java pour les méthodes. Mon équipe était satisfaite avec 🙂

Dépend du langage de programmation.

Jenvisage dutiliser le cas dans le même bateau pour utiliser ou non la notation hongroise:

• Python: underscore_case, pas de notation hongroise
• C ++: camelCase, notation hongroise

Commentaires

• @Kevin Cantu: En fait, le nom Javascript est en PascalCase plutôt quen camelCase …
• @Guffa: touchez é!
• @Kevin Cantu: sur JavaScript: XMLHttpRequest < – Je déteste ce nom wi th une passion.
• hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
• @Lionel: En fait, la notation hongroise nest presque jamais utilisée en C ++, puisque C ++ vérifie déjà vos types. Cest ' plus un artefact historique quautre chose.

Les deux!

Je fais beaucoup de développement dans CakePHP, et jutilise soit CamelCase soit $underscored_vars, de la manière suivante (même en dehors des projets CakePHP):

1. noms de fichiers – /lowercased_underscored.php Typique, mais mérite dêtre mentionné.
2. classes – class CamelCase extends ParentObject. Notez que, lorsque vous utilisez CamelCase, le caractère initial nest pas en minuscules. Je trouve que camelCase semble vraiment bizarre.
3. variables – $are_variables_underscored === TRUE;
4. variables qui contiennent des instances – $CamelCase = new CamelCase();
5. clés de tableau – $collection["underscored_keys"];
6. constantes – Je pense tout le monde peut convenir que les constantes doivent être des ALL_CAPS_AND_UNDERSCORED.
7. méthodes – $CamelCase->foo_method_underscored();
8. méthodes statiques – CamelCase::just_like_regular_methods();

Les commentaires

• doivent être daccord avec vous, le premier caractère étant inférieur laffaire me rend fou! Je déteste camelCase avec passion.
• En Java, où les noms sont typiquement camelCased, les noms de classe commencent en fait par une majuscule. Cest pour les distinguer des noms de méthodes.

Personnellement, je préfère underscore_case parce que je le trouve plus lisible, mais je suis daccord avec les autres répondants qui soulignent que la cohérence avec la base de code existante est beaucoup plus importante.

Cependant, jai un contre-exemple pour ceux qui disent  » suivez la convention de votre langage et de ses bibliothèques « .

Dans le passé, nous écrivions du code C sous Windows en utilisant underscore_case, et nous appelions PascalCase Fonctions Win32:

if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); } 

La distinction visuelle entre nos noms de fonctions et les noms de fonctions de Microsoft était une aide plutôt quun obstacle, car elle clairement montré quand le code entrait dans la « zone système ».

De plus, jai pu modifier les règles de coloration syntaxique de mon éditeur pour les afficher dans différentes couleurs, ce qui a donné des indices visuels supplémentaires en essayant de comprendre des sections de code inconnues (ou même la mienne).

Jaime beaucoup les tirets normaux de Dylan car ils sont-faciles-à-taper-et-faciles -à-lire.

Comme

result-code := write-buffer(file-stream, some-string) 

Mais je suppose que comme ce langage est assez obscur, cest un peu hors sujet. .. 🙁

Commentaires

• Je suis également fatigué dappuyer sur Maj pour taper des traits de soulignement.
• Ce nest généralement pas possible pour les noms de variables, puisque " – " signifie généralement moins.

On ma appris à utiliser camelCase à luniversité. Jai utilisé quelques conventions différentes ces dernières années, mais je préfère camelCase à toute autre chose. Je pense que je me souviens avoir lu quelque part que camelCase est en fait le plus facile à lire et à comprendre.

Commentaires

• eh bien, ' nest pas plus facile car vous avez lu quelque part, cest ' plus facile parce que cétait le premier avec lequel vous avez travaillé et principalement parce que vous y êtes plus habitué, par exemple je ' m plus à laise avec le underscore_case.
• comme dans i ' jai lu quune étude avait été effectuée et je lai trouvée meilleure.

Comme la plupart des gens lont mentionné – Utilisez la norme existante. Sil sagit dun nouveau projet, utilisez la norme pour le langage et les frameworks que vous allez utiliser.

Et ne soyez pas confus, ce nest pas une question de lisibilité (qui est subjective), il sagit d être cohérent et professionnel. Quiconque a travaillé dans une base de code avec de nombreux « standards » en cours comprendra.

Jutilise parfois un mix: module_FunctionName. Toutes les fonctions (non statiques) de mes modules commencent par une abréviation de module.

Par exemple, une fonction pour envoyer le contenu dun tampon sur le bus I2C:

i2c_BufferSend() 

Lalternative i2c_buffer_send ne montre pas une séparation assez grande entre le préfixe et le nom de la fonction. i2cBufferSend se mélange dans le préfixe trop (il y a pas mal de fonctions I2C dans ce module).

i2c_Buffer_send aurait pu être une alternative, cependant.

Ma réponse étant que vous vous adaptez à ce qui fonctionne le mieux pour votre projet (votre langage, votre architecture SW, …), et je tenais à souligner que mélanger ces styles pourrait être utile.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Commentaires

• +1 pour les 2 dernières lignes, mais je ne vous recommande pas de combiner les conventions de dénomination, vous devriez vous en tenir à lune ou auautre.
• Tant que la convention est bien définie (préfixe + trait de soulignement + PascalCase) …
• jaime utiliser des traits de soulignement pour séparer les parties dun nom sémantiquement disjointes fins, en particulier si la similitude de l’une ou l’autre moitié peut être significative. Par exemple, les routines Motor1_Start(), Motor2_Start(), Motor1_Stop() et Motor2_Stop() ont une relation qui pourrait être moins claire sans les traits de soulignement.

Personnellement , Je préfère camelCase, mais dans certaines polices, je pense que les traits de soulignement sont plus faciles à lire.

Je suggère que si vous avez besoin dutiliser des préfixes pour différencier les ensembles de variables, vous devriez utiliser un langage qui vous permet de créer des espaces de noms ou des objets ou quelque chose pour contenir ces informations.

myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 

De même, si vous avez besoin de différencier les types, pourquoi ne pas utiliser un langage qui les autorise?

var intThingy = 7; // :( int thingy = 7; // :) 

Une fois que vous avez ce droit, et que vous nutilisez pas simplement le nom comme méta-données, vous naurez plus de noms suffisamment longs pour importe beaucoup que vous préfériez cette pression supplémentaire ou non.

Commentaires

• Lune des raisons dutiliser camelCase ou underscore_case est que je ne ' t besoin de trouver la définition des objets pour discerner de quoi il sagit.

Au début, je suis daccord avec dafmetal . Il est de la plus haute importance de ne pas mélanger différents styles de programmation. Faire cela dans un seul et même fichier est le pire que vous puissiez faire à mon humble avis. Dans différents fichiers, cest distrayant, mais pas fatal.

La prochaine chose que vous devez faire est de nommer les règles qui sont populaires pour le langage dans lequel vous écrivez. Mon code C ++ pour instnace, va semble différent de quelque chose pour Python évidemment (PEP8 est un bon guide ici)

Vous pouvez également utiliser différentes conventions de dénomination pour faire référence à différentes choses, autant que vous utilisez probablement UPPER_CASE pour les constantes (cela ne sapplique quà certaines langages bien sûr), vous pouvez utiliser this_style pour les noms de variables locales, alors que vous utilisez camelCase pour les variables dinstance / membre. Cela peut ne pas être nécessaire lorsque vous avez des éléments tels que self ou this.

Mise à jour

Prenons un cas où vous avez la plate-forme Foo witch ne recommande aucune convention de dénomination et cest le choix du chef déquipe den choisir une. Vous êtes ce chef déquipe, pourquoi choisiriez-vous camelCase ou pourquoi underscore_case.

Il ny a vraiment aucun avantage pour lun par rapport à lautre. Cette question est très subjective et une fois acceptée, elle ne fera aucune différence. Il y a toujours ces guerres religieuses à propos de ces petites choses. Mais une fois que vous vous êtes adapté à lun ou lautre, les discussions semblent totalement superflues.

Pour citer Alex Martelli sur un sujet très similaire:

Bien sûr, je suis fatigué, en Ruby, de taper le « fin » idiot à la fin de chaque bloc (plutôt que de simplement annuler lindentation) – mais jévite alors de taper le tout aussi stupide « : » qui Python requiert au début de chaque bloc, de sorte que « cest presque un lavage :-). Dautres différences de syntaxe telles que » @foo « par rapport à » self.foo « , ou la signification plus élevée de la casse dans Ruby vs Python, sont vraiment à peu près aussi hors de propos pour moi.

Dautres basent sans aucun doute leur choix de langages de programmation sur ces questions, et ils génèrent les débats les plus chauds – mais pour moi, cest juste un exemple de lune des lois de Parkinson en action ( le montant du débat sur une question est inversement proportionnel à limportance réelle de la question ).

Source

Si vous êtes le chef déquipe, choisissez-en un. Comme lun na aucun avantage par rapport à lautre, vous pouvez simplement lancer des dés ou choisir ce que vous préférez.

Jai lu il y a plusieurs années que les programmeurs qui ne parlent pas langlais comme première langue ont tendance à trouver le cas de soulignement plus facile à comprendre que le cas de chameau – mais je ne trouve pas la référence, et je ne sais pas si cest vrai.

Pour les langages de programmation que jai utilisés, comme Java, Python, C ++, jai adopté un format clair:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Cela me permet de discerner immédiatement ce à quoi je suis confronté. Jai trouvé que cétait utile de le maintenir pour moi-même, et cela devrait être facile à suivre pour quelquun dautre qui lit le code. Je pense que, comme dautres lont mentionné, la cohérence est la plus importante. Je trouve donc mon format être assez simple à maintenir, tout en fournissant des distinctions claires entre les types de noms. Je pourrais imaginer interface_Names_Are_Like_This et Abstract_Classes_Are_Like_This comme des extensions possibles, mais semblent être plus compliquées à suivre et peut-être pas une distinction aussi utile à faire.

Jai également trouvé utile dêtre strict et de nommer des choses dans PascalCase comme un analyseur HTML comme HtmlParser au lieu de HTMLParser ou HTMLparser. Parce que je pense quil est plus facile de se souvenir de la règle stricte et de garder les limites des mots plus claires (malheureusement, cela nécessite des choses mal orthographiées comme HTML ou SQL). De même avec camelCase, htmlParserMethod au lieu de HTMLParserMethod ou HTMLparserMethod.

UPDATE :

Jai depuis lors trouvé une utilisation pour étendre ces règles pour inclure des variables privées.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

En Java, cela signifie que les champs privés sont par définition dans un espace de noms différent de celui des variables locales, ce qui signifie que vous pouvez ignorer le « private id = » 014 « div07 des champs. Autres formats Jai vu le préfixe avec « m« , mais ces formats utilisent également camelCase pour les noms de variables. Cela me permet également de faire une distinction entre les champs qui ne doivent être accessibles quen interne par la classe (et en le rendant super clair quand cela se passe en dehors de la classe object._field_x se démarque).

Si cela ne tenait quà moi, je ne ferais pas valoir ou ne ferais pas allusion à lutilisation dun style particulier car, en tant que programmeurs, nous pourrions être en mesure de lire un symbole IfItIsInCamelCase ou in_underscore_space ou même in_SomeOtherStyle et comprendre ce que cela signifie. Le fait de devoir passer un peu de temps à analyser le symbole nest pas une grande surcharge dans le grand schéma

Maintenant, largument principal dune convention, je suppose, cest que vous savez davance quel est le format dun nom de fonction / variable et que vous navez pas besoin de le rechercher – est-ce LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Maintenant, je voudrais contrer cet argument en disant « Obtenez un IDE qui prend en charge la complétion automatique de style intellisense! » (pas toujours possible cependant).

En fin de compte, le style que vous utilisez n’a pas vraiment d’importance car le compilateur / interpréteur ne s’en soucie pas vraiment. Ce qui est important, cest que le nom soit utile:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Trois styles différents, mais vous savez exactement ce que chacun fait.

Commentaires

• Je ne suis pas daccord, lapparence de la source est importante. Voir " La théorie des fenêtres brisées du programmeur pragmatique " '. Une convention de dénomination variable aggrave lapparence. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Bien que je sois daccord avec le ' fenêtre cassée ' idée, je ne ' pas penser que la capitalisation des symboles constitue une ' fenêtre cassée '. Le code présenté au hasard lest certainement, et mon projet actuel en a certainement beaucoup que jessaie de ranger chaque fois que je le peux.
• Je suis daccord. Je peux lire les trois aussi bien. Cela na ' aucune importance. Jutilise simplement ce que le fichier utilise, puis ce que le langage propose (python) et ensuite tout ce que je pense que le projet sera le mieux servi. (Javais lhabitude de programmer en gwbasic, et cétait en majuscules – le bon vieux temps!)

Cela peut sembler idiot, mais je naime pas les traits de soulignement parce que le trait de soulignement est mince et se cache dans du texte sur plusieurs lignes et je le manque. De plus, dans certains (nombreux) éditeurs de texte et / ou environnements de développement, lorsque vous double-cliquez sur un nom de jeton pour le mettre en surbrillance afin de le copier ou le glisser-déposer, le système ne mettra pas en évidence le jeton entier, il ne met en évidence quune partie du jeton, entre les traits de soulignement adjacents. Cela me rend fou.

Jai tendance à préférer camelCase pour la raison idiote que je fais la plupart de mes développements dans Eclipse (pour Java, PHP et JavaScript), et quand je Ctrl + ← ou Ctrl + → à travers les mots, il sarrête en fait aux limites de camelCase.

Ie: myIntVariable serait traité par Eclipse comme 3 mots lorsque Ct rl + ←   →  »

Je sais que « cest une bizarrerie bizarre, mais je préfère pouvoir modifier les mots du milieu dans un nom camelCase.