Conventions de dénomination: camelCase contre underscore_case? qu'en pensez-vous?
J'utilise underscore_case depuis environ 2 ans et je suis récemment passé à camelCase en raison du nouveau travail (j'utilise le dernier depuis environ 2 mois et je pense toujours que underscore_case est mieux adapté aux grands projets où il y a beaucoup de programmeurs impliqués, principalement parce que le code est plus facile à lire).
Maintenant, tout le monde au travail utilise camelCase parce que (disent-ils) le code semble plus élégant.
Que pensez-vous de camelCase ou underscore_case
p.s. veuillez excuser mon mauvais anglais
Modifier
Quelques mises à jour en premier:
plate-forme utilisée est PHP (mais je ne m'attends pas à des réponses strictes PHP liées à la plate-forme, tout le monde peut partager ses réflexions sur ce qui serait le meilleur à utiliser, c'est pourquoi je suis venu ici en premier lieu)
J'utilise camelCase comme tout autre membre de l'équipe (tout comme la plupart d'entre vous le recommandent)
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 un cas où vous avez la plate-forme Foo qui ne recommande aucune convention de dénomination et que le chef d'équipe a le choix d'en choisir une. Vous êtes ce chef d'équipe, pourquoi choisir camelCase ou pourquoi underscore_case?
p.s. merci à tous pour les réponses rapides jusqu'à présent
Je suis d'accord que cela dépend de la langue que vous utilisez dans une certaine mesure; le code a tendance à être plus net lorsque les noms de vos symboles suivent le même schéma de mise en forme que les bibliothèques intégrées et stock du langage.
Mais là où il y a un choix, je préfère les soulignés aux étuis à chameau, pour une raison simple: je trouve ce style plus facile à lire. Voici un exemple: lequel trouvez-vous le plus lisible? Cette:
aRatherLongSymbolName
ou ca:
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 qu'il ne peut détecter les limites minuscules/majuscules dans le cas du chameau, en particulier lorsque les limites sont entre des glyphes qui ressemblent à d'autres glyphes du cas opposé, ou des chiffres (I/l, O/0, t/I, etc). Par exemple, cette variable booléenne stocke une valeur indiquant si oui ou non 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 encore pire qu'un 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 pouvoir les lire et comprendre leur signification en un coup d'œil. (Je suis sûr que nous lisons tous les imprimés de code au lit pour le plaisir, mais parfois nous grognons à la hâte aussi.) Je trouve souvent avec les noms de symboles d'étui à chameau qu'il est facile de les mal lire et d'avoir la mauvaise impression d'un sémantique du symbole.
Je pense que vous devriez utiliser la convention de dénomination adoptée par votre plateforme. underscore_case sera bizarre dans le code C #, comme camelCase dans Ruby =)
Honnêtement, cela n'a pas vraiment d'importance tant que tout le monde dans l'équipe utilise le même schéma. Il y a des chances que l'une ou l'autre soit plus naturelle pour vous, bien que la véritable importance soit la lisibilité du code à long terme et qu'il est alors crucial que tout le monde adhère aux mêmes règles de dénomination.
Sur la base d'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 quelques recherches et j'ai trouvé cet article . Qu'est-ce que la science a à dire sur le sujet?
- L'enveloppe de chameau a une plus grande probabilité de correction que les soulignés. (les chances sont 51,5% plus élevées)
- En moyenne, l'affaire des chameaux a pris 0,42 seconde de plus , soit 13,5% de plus.
- La formation n'a pas d'impact statistiquement significatif sur la façon dont le style influe sur l'exactitude.
- Ceux avec plus de formation étaient plus rapides sur les identifiants dans le style de cas de chameau.
- La formation 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 l'article scientifique et tire la conclusion suivante.
Seule la lenteur de l'affaire des chameaux (2) est vraiment pertinente pour la programmation, rejetant les autres points comme non pertinents en raison de IDE modernes et une majorité d'utilisateurs de camelCase dans l'étude. La discussion (avec un sondage) peut être trouvée sur le blog.
Je suis curieux de voir comment cet article pourrait changer d'avis. :)
Copiez les gars 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 cela se fait dans K&R.
Ensuite, quand quelqu'un essaie de démarrer une conversation de style de codage ennuyeux, je peux lui dire "en parler avec Dennis Ritche et faites-moi savoir ce qu'il dit."
En général, je préfère camelCase. Cependant, c'est parce que la plupart de ma carrière, j'ai travaillé dans des langages et des environnements où les guides de style recommandent normalement camelCase. (Java, ECMAScript, C++). Vous, étant une personne PHP, vous aurez probablement la préférence opposée.
Cela dit, lorsque vous allez au-delà de threeOrFourWords, ou si vous utilisez des initialismes comme XmlForExample, cela cesse d'être aussi lisible.
C'est pourquoi emacs nous propose le mode lunettes.
camelCase
C'est l'un des rares endroits où je choisirai toujours la "capacité de type" plutôt que la lisibilité. CamelCase est simplement plus facile à taper, et être plus gentil avec mes doigts l'emporte sur un léger gain de lisibilité pour moi.
en supposant bien sûr que le projet ne s'appuie pas sur une base de code existante avec un standard différent.
C'est une question intéressante, j'y ai pensé plusieurs fois. Mais il n'y a pas de réponse définitive, je pense.
Suivant les conventions "culturelles", c'est un bon choix. "Culturel" dans ce cas signifie des conventions établies dans l'équipe/entreprise et elles portent essentiellement les conventions de langue/plate-forme également. Il aide les autres à lire/utiliser votre code facilement et ne nécessite pas d'efforts et de temps supplémentaires pour se familiariser avec votre code.
Parfois, il est intéressant de casser les notations acceptées. Un de mes petits projets (sur Python) j'ai utilisé underscored_names pour les fonctions utilitaires/méthodes "protégées" et Java-style methodNames pour les méthodes. Mon équipe en était satisfaite :)
Dépend du langage de programmation.
Je pense utiliser le cas dans le même bateau pour savoir si oui ou non utiliser 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 j'utilise CamelCase ou $underscored_vars, De la manière suivante (même en dehors des projets CakePHP):
- noms de fichiers -
/lowercased_underscored.phpTypique, mais mérite d'être mentionné. - classes -
class CamelCase extends ParentObject. Notez que lorsque vous utilisezCamelCase, le caractère initial n'est pas en minuscule. Je trouve quecamelCasea l'air vraiment bizarre. - variables -
$are_variables_underscored === TRUE; - variables qui contiennent des instances -
$CamelCase = new CamelCase(); - clés du tablea -
$collection['underscored_keys']; - constantes - Je pense que tout le monde peut convenir que les constantes doivent être
ALL_CAPS_AND_UNDERSCORED. - méthodes -
$CamelCase->foo_method_underscored(); - méthodes statiques -
CamelCase::just_like_regular_methods();
Personnellement, je préfère underscore_case parce que je le trouve plus lisible, mais je suis d'accord avec les autres répondants qui soulignent que la cohérence avec la base de code existante est beaucoup 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 sur Windows en utilisant underscore_case, et appelé PascalCase Fonctions Win32:
if (one_of_our_conditions_is_true())
{
call_one_of_our_functions();
CallSystemFunction();
}
La distinction visuelle entre nos noms de fonction et les noms de fonction de Microsoft a été une aide plutôt qu'un obstacle, car elle montrait clairement quand le code entrait dans le "système land".
De plus, j'ai pu modifier les règles de coloration syntaxique de mon éditeur pour les afficher dans différentes couleurs, ce qui a donné d'autres indices visuels lorsque j'essayais de comprendre des sections de code inconnues (ou même les miennes).
J'aime vraiment les tirets juste-normaux de Dylan car ils sont faciles à taper et à lire.
Comme
result-code := write-buffer(file-stream, some-string)
Mais je suppose que cette langue est assez obscure, c'est un peu hors sujet ... :(
On m'a appris à utiliser camelCase à l'université. J'ai utilisé plusieurs conventions différentes au cours des 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.
Personnellement, je préfère camelCase, mais dans certaines polices, je pense que les soulignés sont plus faciles à lire.
Je suggérerais que si vous avez besoin d'utiliser des préfixes pour différencier des 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 bien compris et que vous n'utilisez pas simplement le nom comme métadonnées, vous n'aurez pas assez de noms longs pour que cela soit très important, que vous préfériez cette touche supplémentaire ou non.
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 y trompez pas, il ne s'agit pas de lisibilité (qui est subjective), il s'agit d'être cohérent et professionnel. Quiconque a travaillé dans une base de code avec de nombreuses "normes" en cours comprendra.
J'utilise 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 un contenu de tampon sur le bus I2C:
i2c_BufferSend()
L'alternative i2c_buffer_send n'affiche pas une séparation suffisamment grande entre le préfixe et le nom de la fonction. i2cBufferSend mélange trop le préfixe (il y a pas mal de fonctions I2C dans ce module).
i2c_Buffer_send pourrait cependant être une alternative.
Ma réponse étant que vous vous adaptez à ce qui fonctionne le mieux pour votre projet (votre langue, votre architecture SW, ...), et je tenais à souligner que le mixage de ces styles pourrait être utile.
myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.
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 à quoi je fais face. J'ai trouvé que c'était utile à maintenir pour moi-même, et cela devrait être facile à suivre pour quelqu'un d'autre qui lit le code. Je pense que, comme d'autres l'ont mentionné, la cohérence est la plus importante. Je trouve donc que mon format est assez simple à maintenir, tout en offrant 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 semble être plus compliqué à suivre et peut-être pas aussi utile une distinction à faire.
J'ai é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 qu'il est plus facile de se souvenir de la règle stricte et de garder les limites de Word plus claires (malheureusement, cela nécessite des fautes d'orthographe comme HTML ou SQL). De même avec camelCase, htmlParserMethod au lieu de HTMLParserMethod ou HTMLparserMethod.
MISE À JOUR :
Depuis, j'ai trouvé utile d'é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 des variables locales, ce qui signifie que vous pouvez ignorer le this. sur des champs privés. J'ai vu d'autres préfixes 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 qu'en interne par la classe (et de le rendre super clair quand cela se produit en dehors de la classe object._field_x se démarque).
Au début, je suis d'accord avec le 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, c'est gênant, 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 sera 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 s'applique qu'à certaines langues bien sûr), vous pouvez utiliser this_style pour les noms de variables locaux, tandis que vous utilisez camelCase pour exemple/membre variables. Cependant, 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 nommage et que le chef d'équipe a le choix d'en choisir une. Vous êtes ce chef d'équipe, pourquoi choisir camelCase ou pourquoi underscore_case.
Il n'y a vraiment aucun avantage l'un par rapport à l'autre. Cette question est très subjective et une fois convenue, elle ne fera aucune différence. Il y a toujours ces guerres de religion à propos de ces petites choses. Mais une fois que vous vous êtes ajusté à l'un ou l'autre, les discussions semblent être entièrement superflues.
Pour citer Alex Martelli sur un sujet très similaire:
Bien sûr, je suis fatigué, en Ruby, de taper la "fin" idiote à la fin de chaque bloc (plutôt que de simplement indenter) - mais alors j'arrive à éviter de taper l'également idiot ':' qui Python nécessite au début de chaque bloc, c'est donc presque un lavage :-). D'autres différences de syntaxe telles que '@foo' contre '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.
D'autres fondent sans aucun 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 d'une des lois de Parkinson en action ( le montant du débat sur un problème est inversement proportionnelle à l'importance réelle du problème ).
Si vous êtes le chef d'équipe, vous n'avez qu'à en choisir un. Étant donné que l'un n'a aucun avantage sur l'autre, vous pouvez simplement lancer des dés ou choisir ce que vous aimez le plus.
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 le soulignement plus facile à comprendre ce cas de chameau - mais je ne trouve pas la référence, et je n'ai aucune idée si c'est vrai.
Si cela ne tenait qu'à moi, je n'appliquerais ni n'indiquerais l'utilisation d'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. Avoir à passer une petite quantité de temps à analyser le symbole n'est pas un gros frais généraux dans le grand schéma des choses.
Maintenant, l'argument principal pour une convention, je suppose que vous savez d'avance quel est le format d'un nom de fonction/variable et n'avez pas besoin de le rechercher - est-ce LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Maintenant, je contrerais 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 que vous utilisez car le compilateur/interprète ne se 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.
J'ai tendance à préférer camelCase pour la raison stupide que je fais la plupart de mon développement dans Eclipse (pour Java, PHP et JavaScript), et quand je Ctrl+← ou Ctrl+→ à travers les mots, il s'arrête en fait aux limites de camelCase.
C'est-à-dire: myIntVariable serait traité par Eclipse comme 3 mots lorsque Ctrl+← →'traverser.
Je sais que c'est une bizarrerie bizarre, mais je préfère pouvoir éditer les mots du milieu dans un nom camelCase.
Cela peut sembler idiot, mais je n'aime pas les traits de soulignement parce que le trait de soulignement est mince et se cache dans le texte sur plusieurs lignes et il me 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 faire glisser et le déposer, le système ne mettra pas en surbrillance tout le jeton, il ne mettra en surbrillance qu'une partie du jeton, entre les traits de soulignement adjacents. Cela me rend fou.