Conventions de dénomination: camelCase versus underscore_case? que pensez-vous de cela? [fermé]

J'utilise underscore_case depuis environ 2 ans et je suis récemment passé à camelCase en raison de mon nouvel emploi (j'utilise le dernier emploi depuis environ 2 mois et je pense toujours que underscore_case convient mieux aux grands projets où de nombreux programmeurs sont impliqués, principalement parce que le code est plus facile à lire).

Maintenant, tout le monde au travail utilise camelCase car (dit-on) le code est plus élégant.

Quelles sont vos pensées sur camelCase ou underscore_case

ps s'il vous plaît excuser mon mauvais anglais

Modifier

Quelques mises à jour en premier:

• la plate-forme utilisée est PHP (mais je ne m'attends pas à des réponses strictes concernant la plate-forme PHP, tout le monde peut donner son opinion sur ce qui serait le mieux à utiliser, c'est pourquoi je suis venu ici en premier lieu)

• J'utilise camelCase comme un membre de l'équipe (comme le recommandent la plupart d'entre vous)

• nous utilisons Zend Framework qui recommande également camelCase

Quelques exemples (liés à PHP):

• Le framework Codeigniter recommande underscore_case, et honnêtement, le code est plus facile à lire.

• ZF recommande camelCase et je ne suis pas le seul à penser que le code ZF est un peu plus difficile à suivre.

Donc ma question serait reformulée:

Prenons le cas où vous avez la plate-forme Foo qui ne recommande aucune convention de nommage et que le choix du chef d'équipe est de choisir. Vous êtes ce chef d'équipe, pourquoi choisiriez-vous camelCase ou pourquoi underscore_case?

ps merci à tous pour les réponses rapides jusqu'à présent

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

Mais là où il y a un choix, je préfère les soulignés au camel, pour une raison simple: je trouve ce style plus facile à lire. Voici un exemple: lequel trouvez-vous plus lisible? Cette:

aRatherLongSymbolName

ou ca:

a_rather_long_symbol_name

Je trouve la version soulignée beaucoup plus facile à lire. Mon cerveau peut ignorer les underscores beaucoup plus facilement qu'il peut détecter les limites minuscules / majuscules en cas de chameau, en particulier lorsque les limites sont entre glyphes qui ressemblent à d' autres 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 une autorisation de planification appropriée (sans aucun doute un cas d'utilisation courant pour nous tous):

isIllicitIgloo

Je trouve cette version beaucoup plus facile à lire:

is_illicit_igloo

Peut-être même pire qu'un nom de symbole difficile à lire est un nom de symbole facile à interpréter de manière erronée. Les bons noms de symboles s'auto-documentent, ce qui pour moi signifie 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 copies de code au lit pour le plaisir, mais de temps en temps nous parlons aussi vite.) la sémantique du symbole.

Je pense que vous devriez utiliser la convention de nommage adoptée par votre plate-forme. underscore_case sera bizarre en code C #, comme camelCase en Ruby =)

Honnêtement, cela n'a pas vraiment d'importance tant que tous les membres de l'équipe utilisent le même schéma. Les chances sont que l’un ou l’autre vous semble plus naturel, bien que l’importance réelle soit la lisibilité du code à long terme et qu’il est donc crucial que tout le monde adhère aux mêmes règles de nommage.

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

"honnêtement, le code est plus facile à lire" Opinion ou fait?

J'ai décidé de faire des recherches et j'ai trouvé ce papier . Qu'est-ce que la science a à dire sur le sujet?

1. Le boîtier en chameau a une plus grande probabilité de correction que le trait de soulignement. (les chances sont 51.5% plus élevées)
2. En moyenne, les cas de chameaux ont pris 0,42 seconde de plus , soit 13,5% de plus.
3. La formation n’a aucun impact statistiquement significatif sur la manière dont le style influence la correction.
4. Ceux qui avaient reçu une formation plus poussée identifiaient plus rapidement les identifiants dans le cas des chameaux.
5. La formation dans un style affecte négativement le temps de recherche des autres styles.

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

Seule la lenteur de Camel Case (2) est réellement pertinente pour la programmation, les autres points étant considérés comme non pertinents en raison des IDE modernes et de la majorité des utilisateurs de camelCase étudiés. La discussion (avec un sondage) peut être trouvée sur le blog.

Je suis curieux de savoir comment cet article pourrait changer d'opinion. :)

Copiez les plus intelligents

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

Par exemple, je code C exactement comme dans K & R.

Ensuite, lorsque quelqu'un essaie de lancer une conversation ennuyeuse sur le style de codage, je peux leur dire "évoquez-le avec Dennis Ritche et laissez-moi savoir ce qu'il dit".

En général, je préfère camelCase. Cependant, c’est parce que la majeure partie de ma carrière s’est déroulée dans des langues et des environnements où les guides de style recommandent normalement camelCase. (Java, ECMAScript, C ++). En tant que personne PHP, vous aurez probablement la préférence opposée.

Cela dit, lorsque vous allez au-delà de trois Ou Quatre, ou si vous utilisez des initiales commeXmlForExample, cela cesse d’être aussi lisible.

C'est pourquoi emacs nous donne le mode lunettes.

affaire de chameau

C’est l’un des rares endroits où je choisirai toujours «capacité typographique» à la lisibilité. CamelCase est tout simplement plus facile à taper, et être plus agréable à mes doigts gagne 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.

C'est une question intéressante à laquelle j'ai souvent réfléchi. Mais il n'y a pas de réponse définitive, je pense.

Suivre les conventions "culturelles" est un bon choix. Dans ce cas, le terme "culturel" désigne les conventions établies dans l'équipe / la société et porte essentiellement les conventions de langage / plate-forme. Cela aide les autres à lire / utiliser votre code facilement et ne nécessite pas d'efforts et de temps supplémentaires pour entrer dans la compréhension de votre code.

Parfois, il est intéressant de casser les notations acceptées. Un de mes petits projets (sur Python) que j'ai utilisé underscored_namespour les fonctions utilitaires / méthodes "protégées" et le style Java methodNamespour les méthodes. Mon équipe était contente :)

Dépend du langage de programmation.

J’envisage d’utiliser la casse dans le même bateau de l’utilisation ou non de la notation hongroise:

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

Tous les deux!

Je fais beaucoup de développement dans CakePHP, et je l' utilise soit CamelCaseou $underscored_vars, de la manière suivante (même en dehors CakePHP Projets):

1. noms de fichiers - /lowercased_underscored.phpTypiques, mais à noter.
2. classes - class CamelCase extends ParentObject. Notez que, lors de l'utilisation CamelCase, le caractère initial n'est pas en minuscule. Je trouve camelCaseregarder vraiment bizarre.
3. variables -$are_variables_underscored === TRUE;
4. variables qui contiennent des instances -$CamelCase = new CamelCase();
5. tableau de clés -$collection['underscored_keys'];
6. constantes - Je pense que tout le monde peut convenir que les constantes devraient l'être ALL_CAPS_AND_UNDERSCORED.
7. méthodes -$CamelCase->foo_method_underscored();
8. méthodes statiques -CamelCase::just_like_regular_methods();

Personnellement, je préfère underscore_caseparce que je le trouve plus lisible, mais je suis d’accord avec les autres intervenants qui soulignent que la cohérence avec le code de base existant est bien plus importante.

Cependant, j'ai un contre-exemple pour ceux qui disent "suivez la convention de votre langue et de ses bibliothèques".

Dans le passé, nous écrivions du code C sous Windows en underscore_caseappelant PascalCaseles fonctions Win32:

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

La distinction visuelle entre les noms de nos fonctions et les noms des fonctions de Microsoft constituait une aide plutôt qu'une entrave, comme le montrait clairement le moment où le code passait au "système".

En outre, j'ai pu modifier la syntaxe de mon éditeur pour mettre en évidence les règles et les afficher de différentes couleurs, ce qui donnait des indices visuels supplémentaires lorsque l'on essayait de comprendre des sections de code inconnues (ou même les miennes).

J'aime beaucoup les traits de Dylan, qui sont tout à fait normaux, comme ils sont faciles à dactylographier et à lire.

Comme

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

Mais je suppose que comme ce langage est assez obscur, c'est un peu hors sujet ... :(

On m'a appris à utiliser camelCase à l'université. J'ai utilisé différentes conventions ces dernières années, mais je préfère camelCase à toute autre chose. Je pense me rappeler avoir lu quelque part que camelCase est en fait le plus facile à lire et à comprendre.

Comme la plupart des gens l'ont mentionné, utilisez la norme existante. S'il s'agit d'un nouveau projet, utilisez la norme pour le langage et les frameworks que vous utiliserez.

Et ne vous trompez pas, il ne s'agit pas de lisibilité (qui est subjective), mais de cohérence et de professionnalisme. Quiconque a travaillé dans une base de code avec de nombreuses «normes» en cours comprendra.

J'utilise parfois un mélange: module_nomfonction. Toutes les fonctions (non statiques) de mes modules commencent par une abréviation de module.

Par exemple, une fonction permettant d'envoyer le contenu d'un tampon sur le bus I2C:

i2c_BufferSend()

L'alternative i2c_buffer_sendn'indique pas une séparation suffisamment grande entre le préfixe et le nom de la fonction. i2cBufferSendmixe trop dans le préfixe (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 le mélange de ces styles pourrait être utile.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Je_respect_le_fact_que_quel_que_pouvait_penser_par ailleurs_but_I_do_not_ pas vraiment_simplement_si.

Personnellement, je préfère camelCase, mais dans certaines polices, les caractères de soulignement sont plus faciles à lire.

Je suggérerais que si vous devez utiliser des préfixes pour différencier des ensembles de variables, vous devez utiliser un langage qui vous permet de créer des espaces de noms, des objets ou quelque chose qui contient ces informations.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

De même, si vous devez différencier les types, pourquoi ne pas utiliser un langage qui leur permet?

var intThingy = 7; // :(

int thingy = 7;    // :)

Une fois que vous avez compris, et que vous n'utilisez pas simplement le nom en tant que métadonnées, vous n'aurez pas assez de noms trop longs pour que le fait que vous préfériez ou non cette touche importe peu.

Au début, je suis d'accord 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. Sur différents fichiers, cela distrait mais n'est pas fatal.

La prochaine chose que vous devez faire est d’appeler les règles de nommage qui sont populaires pour le langage que vous écrivez. Mon code C ++ pour instnace sera différent de celui de Python (PEP8 est ici un bon guide)

Vous pouvez également utiliser différentes conventions de dénomination pour faire référence à différentes choses, même si vous utilisez probablement UPPER_CASE pour les constantes (cela ne s'applique évidemment qu'à certaines langues), vous pouvez utiliser this_style pour les noms de variables locales, alors que vous utilisez camelCase pour instance / membre variables. Cela peut ne pas être nécessaire lorsque vous avez des choses comme selfou comme this.

Mise à jour

Prenons le cas où vous avez la plate-forme Foo Witch ne recommande aucune convention de nommage et le choix du chef d'équipe en est une. Vous êtes ce chef d’équipe, pourquoi choisiriez-vous camelCase ou pourquoi underscore_case?

Il n'y a vraiment aucun avantage pour l'un sur l'autre. Cette question est très subjective et une fois acceptée, elle ne fera aucune différence. Il y a toujours ces guerres récurrentes sur ces petites choses. Mais une fois que vous vous êtes ajusté à l'un ou l'autre, les discussions semblent être totalement superflues.

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

Bien sûr, en Ruby, je me lasse de taper le "fin" idiot à la fin de chaque bloc (plutôt que de le laisser indifférent) - mais je ne peux pas non plus taper le "aussi" idiot que Python exige à le début de chaque bloc, donc c'est presque un lavage :-). D'autres différences de syntaxe telles que "@foo" par rapport à "self.foo", ou la signification plus importante de case dans Ruby vs Python, sont tout aussi importantes pour moi.

D'autres fondent sans doute leur choix de langages de programmation sur de telles questions et génèrent les débats les plus chauds - mais pour moi, ce n'est qu'un exemple de la loi de Parkinson en action ( le montant du débat sur une question est inversement proportionnel à celui de la question importance réelle ).

La source

Si vous êtes le chef d’équipe, vous n’allez qu’avec un seul. Étant donné que l’un n’a aucun avantage sur l’autre, vous pouvez lancer des dés ou choisir ce que vous préférez.

J'ai lu il y a plusieurs années que les programmeurs qui ne parlent pas l'anglais comme première langue ont tendance à trouver les soulignés plus faciles à comprendre, mais je ne trouve pas la référence, et je ne sais pas si c'est vrai.

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

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Cela me permet de discerner immédiatement de quoi j'ai affaire. J'ai trouvé cela utile à maintenir pour moi-même, et il devrait être facile à suivre pour quelqu'un d'autre qui lit le code. Je pense que comme d’autres ont mentionné la cohérence est le plus important. Je trouve donc que mon format est 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 cela semble plus compliqué à suivre et peut-être pas aussi utile de faire une distinction.

J'ai également trouvé utile d'être strict et de nommer des éléments dans PascalCase, tels qu'un analyseur syntaxique HTML tel que HtmlParser au lieu de HTMLParser ou HTMLparser. Parce que je pense qu'il est plus facile de se rappeler la règle stricte et de garder les limites de mots plus claires (malheureusement, cela nécessite des fautes d'orthographe telles que HTML ou SQL). De même avec camelCase, htmlParserMethod au lieu de HTMLParserMethod ou HTMLparserMethod.

MISE À JOUR :

Depuis, j'ai trouvé utile d'élargir 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 nom différent des variables locales, ce qui signifie que vous pouvez ignorer les this.champs privés. Les autres formats que j'ai vus préfixent " m", mais ces formats utilisent également camelCase pour les noms de variables. Cela me permet également de faire la distinction entre les champs auxquels la classe ne devrait accéder qu'en interne (et le rendre très clair lorsque cela se passe en dehors de la classe object._field_xse démarque).

Si c’était à moi, je ne ferais pas allusion à un style particulier, car en tant que programmeurs, nous pourrions lire un symbole IfItIsInCamelCase ou in_underscore_space ou même in_SomeOtherStyle et comprendre ce que cela signifie. Le fait de passer un temps infime à analyser le symbole n’est pas une lourde charge dans le grand agencement.

Maintenant, le principal argument pour une convention, je suppose, est que vous savez dès le départ quel est le format d’un nom de fonction / variable et que vous n’avez pas besoin de le rechercher - est-ce LoadXMLFile, loadXMLFile, LoadXmlFile, 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, peu importe le style utilisé, le compilateur / interprète ne s'en soucie pas vraiment. Ce qui est important c'est que le nom soit utile:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

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

Cela peut sembler idiot, mais je n'aime pas les caractères de soulignement, car celui-ci est mince et se cache dans un texte de plusieurs lignes et il me manque. De plus, dans certains (plusieurs) éditeurs de texte et / ou environnements de développement, lorsque vous double-cliquez sur un nom de jeton pour le surligner afin de le copier ou de le déposer, le système ne met pas en surbrillance le jeton entier, il ne met en surbrillance qu'une partie. du jeton, entre les traits de soulignement adjacents. Cela me rend fou.

J'ai tendance à préférer camelCase pour la raison idiote que je réalise l'essentiel de mon développement sous Eclipse (pour Java, PHP et JavaScript), et lorsque I Ctrl+ ←ou Ctrl+ à →travers des mots, il s'arrête en réalité aux limites de camelCase.

À savoir: myIntVariableserait traité par Eclipse 3 mots quand Ctrl+ ← →« ing à travers elle.

Je sais que c'est une bizarrerie bizarre, mais je préfère me permettre de modifier les mots du milieu dans un nom camelCase.