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


70

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


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

9
Pensez qu'ils sont tous les deux à peu près le même mais que je pense à leur mélange.
dietbuddha

7
@dietbuddha: Je viens de lire 'but_i_think_mixing_them_is_pretty_bad' beaucoup plus rapidement que 'IThinkTheyAreBothAboutTheSame'. Je suis à peu près sûr que cela peut être prouvé scientifiquement. :)
Steven Jeuris

@ John Isaacks: Je suis triste de pouvoir annoncer (en tant que défenseur du sous-jacent) qu'une étude a conclu que "le boîtier en chameau permet une plus grande précision parmi tous les sujets, quelle que soit leur formation" .
Steven Jeuris

IWonderWheretherhetherreadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference. InTheEnd, IFindThatNeitherIsVeryGoodAtBeingEasyToRead. Il_écoule_horriblement_avec_la_longueur_de_ligne_et_makes_even_le_simplest_thing_compliqué. I_wonder_whether_there_there_would_be_support_langue_en_du_future_pour_quotait_nom_variable_nom. "Cela serait beaucoup plus logique à mon avis que camelCase ou underscore_separators".
Christopher Mahan

Réponses:


84

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.


25
Un problème avec les underscores: la convivialité. Pour la plupart des claviers (européens), taper le signe de soulignement nécessite de maintenir la touche MAJ enfoncée. Vous devez également faire cela pour camelCase, mais je peux facilement maintenir SHIFT avec le petit doigt et taper n'importe quelle lettre. flux de dactylographie.
LearnCocos2D

11
Pour le premier, j’ai trouvé que camelCase était plus facile à lire, bien que ce dernier soit évidemment différent.
Phoshi

19
Cela dépend de ce que vous avez l'habitude de faire. Je trouve camelCases easyToRead plus facile à lire, et en plus, ils sont plus courts que les noms de soulignement équivalents.
Joonas Pulakka

17
Je déteste taper des caractères de soulignement.
EpsilonVector

6
Le point "utilisabilité" est sans importance pour cela. Le code est généralement écrit une seule fois par une seule personne, mais disons de l'ordre de 1 à 10 fois, ce qui représente une édition et une programmation par paire potentielle. Mais le code est généralement lu des dizaines, des centaines, des milliers de fois par une personne, voire par de nombreuses personnes. Rendre le code facile à lire est donc beaucoup plus important que d'avoir un code facile à écrire.
hlovdal

97

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 =)


23
La cohérence est une clé. Que vous soyez d'accord avec la convention locale ou non, vous ferez en sorte que votre temps soit plus facile (et celui de tous les autres) en étant cohérent. (À moins que la convention locale ne soit elle-même une incohérence.) De plus, la lisibilité est un argument généralement faux: lisez suffisamment de code pour découvrir qu'il y a peu de différence, à moins que vous ne décidiez qu'il est illisible.
Richard

1
Entièrement d'accord. Je pense simplement qu'il est préférable d'utiliser la convention de plate-forme plutôt que les conventions personnalisées, car par exemple, les nouveaux membres de l'équipe se sentiront plus à l'aise avec cela.
Alexey Anufriyev

2
Mais malheur à ceux d'entre nous qui travaillons sur deux plateformes avec deux conventions, où certaines préfèrent et d'autres préfèrent l'autre!
Michael K

Si la plate-forme a deux conventions, je demanderais à tous les membres de l'équipe de voter pour une convention avec laquelle ils sont à l'aise =)
Alexey Anufriyev

20

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.


vous avez tout à fait raison, mais j’essaie de connaître l’opinion des gens sur ce qu’il serait préférable d’utiliser (disons pour toute l’équipe), et pourquoi ... alors que je comprends que certaines personnes pourraient être juste habituées à une convention ou d'autres semblent plus naturels avec l'autre.
Poelinca

20

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. :)


3
Bien sûr, vous rejetez tous les autres points à cause de votre préférence pour les traits de soulignement et les autres points ne vous aident pas ...
Charles Boyung

2
@ Charles: Oui et non, à mon humble avis, je fais bien valoir les raisons pour lesquelles ils sont destituables, et certains d'entre eux sont même considérés comme problématiques par le journal lui-même. Un document de suivi examine certains des problèmes de ce document et les résultats obtenus sont favorables à la sous-traitance.
Steven Jeuris

11

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".


12
L'original n'est pas toujours le meilleur. Il existe de nombreuses mauvaises pratiques dans le livre d'évangile de K & R sur C. Avant que cela ne déclenche une guerre des flammes ... lisez certaines des recommandations de MISRA.
Rapid_now

10
N'oubliez pas que K & R a été écrit quand il n'y avait pas de GUI-IDE. La plupart des travaux ont été effectués sur des terminaux de 80 caractères x 25 caractères; l'espace à l'écran était donc primordial, ce qui if (...) {permettait de sauvegarder une ligne! Ces jours-ci, il y a plus d'espace à l'écran - K & R serait-il différent s'il était écrit aujourd'hui avec des IDE haute résolution pour interfaces graphiques et plusieurs configurations de moniteur?
Skizz

3
Oui, mais quand quelqu'un dit qu'il a le code C comme K & R, il a des accessoires pour être vieux.
Christopher Mahan

3
@quickly_now, parlez-en à Dennis Ritchie et dites-moi ce qu'il a dit!
Mark Harrison

J'adopte beaucoup de formatage à partir de MS: _internalToClassOnly, accessibleByGetter, PublicVariable.
Résumé de

10

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.


2
+1 pour me faire découvrir le mode lunettes! Je viens de le tester sur un fichier de code qui utilise camelCase et j'ai remarqué que le résultat était immédiatement meilleur (assemblage avec beaucoup d'étiquettes dans camelCase).
Gauthier

Ok, c'est quoi le mode lunettes?
Marcie


8

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.


Je ne suis pas d'accord avec ça, vous écrivez du code une seule fois, mais vous devez le lire plusieurs fois par la suite
Roman Pekar

7

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 :)


6

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

8
@ Kevin Cantu: En réalité, le nom Javascript est dans PascalCase plutôt que dans camelCase ...
Guffa

1
@Guffa: touché!
Kevin Cantu

2
@ Kevin Cantu: sur JavaScript: XMLHttpRequest<- Je déteste ce nom avec passion.
Thanatos

1
hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
Kevin Cantu

4
@ Lionel: En réalité, la notation hongroise n'est presque jamais utilisée en C ++, car C ++ vérifie déjà vos types. C'est plus un artefact historique qu'autre chose.
In silico

6

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();

3
Je suis d'accord avec vous, le fait que le premier caractère soit en minuscule me rend fou! Je déteste camelCase avec passion.
HLGEM

En Java, où les noms sont typiquement camelCased, les noms de classe commencent en réalité par une lettre majuscule. C'est pour les distinguer des noms de méthodes.
James P.

5

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).


5

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 ... :(


3
Je suis aussi fatigué de devoir appuyer sur Maj pour taper des caractères de soulignement.
Gauthier

8
Ce n'est généralement pas possible pour les noms de variables, car "-" signifie généralement moins.
Eric Wilson

4

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.


4
Eh bien, ce n’est pas plus facile, car vous lisez quelque part, c’est plus facile, c’est le premier travail avec lequel vous avez travaillé et surtout parce que vous y êtes plus habitué, par exemple, je suis plus à l’aise avec underscore_case.
Poelinca

1
comme dans j'ai lu qu'une étude a été faite et a trouvé que c'était mieux ..
Ross

4

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.


4

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.


1
+1 pour les 2 dernières lignes, mais je ne vous recommande pas de combiner les conventions de dénomination, vous devez vous en tenir à l'une ou à l'autre.
Poelinca

Tant que la convention est bien définie (préfixe + trait de soulignement + PascalCase) ...
Gauthier

J'aime utiliser des traits de soulignement pour séparer les parties d'un nom dont le but est sémantiquement disjoint, en particulier si la similitude sur l'une ou l'autre moitié peut être importante. Par exemple, les routines Motor1_Start(), Motor2_Start(), Motor1_Stop()et Motor2_Stop()ont une relation qui pourrait être moins claire , sans les underscores.
Supercat

4

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.


1
Une des raisons d'utiliser camelCase ou underscore_case est que je n'ai pas besoin de trouver la définition des objets pour savoir ce que c'est.
Joshua Shane Liberman

2

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.


2

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.


2

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).


1

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.


1
Je prie de différer, l'apparence de la source est importante. Voir "Le programmeur pragmatique" sur la théorie des fenêtres cassées. La modification des conventions de nommage aggrave l'apparence. pragprog.com/programmer-pragmatic/extracts/entrale-software
Gauthier

1
@ Gauthier: Bien que je sois d'accord avec l'idée de "fenêtre brisée", je ne pense pas que la capitalisation des symboles constitue une "fenêtre brisée". Le code élaboré par hasard est certainement le cas, et mon projet actuel contient certainement beaucoup de ce que je tente de ranger chaque fois que je peux.
Skizz

Je suis d'accord. Je peux lire les trois aussi bien. Ça n'a pas d'importance. J'utilise simplement ce que le fichier utilise, puis tout ce que le langage propose (python), puis tout ce qui, à mon avis, servira au mieux le projet. (J'avais l'habitude de programmer en gwbasic, et c'était tout en majuscules - le bon vieux temps!)
Christopher Mahan

0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.