Quelle est la raison de l'utilisation des minuscules pour le premier mot d'une variable locale (par exemple, employeeCount, firstName)


20

Je reçois beaucoup de critiques de la part d'autres programmeurs en raison de mon utilisation d'un boîtier complet pour toutes mes variables. Par exemple, votre programmeur typique utilisera employeeCountun nom de variable, mais j'utilise EmployeeCount. J'utilise un boîtier complet pour tout , que ce soit une méthode void, une méthode de retour, une variable, une propriété ou une constante. Je respecte même cette convention en Javascript. Cette dernière brouille vraiment les jimmies des gens.

La raison typique donnée pour laquelle je ne devrais pas suivre cette convention de casse "non standard" est parce que le cas complet doit être réservé aux propriétés et aux méthodes void. La variable locale et les méthodes qui renvoient une valeur doivent avoir le premier mot en minuscule comme int employeeCount = getEmployeeCount().

Cependant, je ne comprends pas pourquoi.

Quand je remets cela en question, il semble que je reçois simplement une réponse arbitraire de c'est la norme . Quelle que soit la réponse, cela se résume généralement à: C'est juste comme ça et je ne le remets pas en question. Je viens de le suivre. . Les réponses arbitraires ne sont jamais assez bonnes pour moi.

Depuis mes premiers jours de programmation de macros Excel 97 avec l'IDE Office, je n'ai jamais eu besoin d'une convention de casse pour me dire si quelque chose est une variable ou une propriété locale. C'est parce que j'ai toujours utilisé une convention de dénomination très intuitive. Par exemple, GetNuggetCount()suggère clairement une méthode qui va quelque part et obtient un décompte de toutes les pépites. SetNuggetCount(x)suggère que vous affectez une nouvelle valeur au nombre de nuggets. NuggetCounttout seul suggère une propriété ou une variable locale qui contient simplement une valeur. À ce dernier, on peut être tenté de dire: "Ah ha! Telle est la question. Propriété ou variable? QUI EST-CE?" À cela, je répondrais: "Est-ce vraiment important?"

Voici donc le tl; dr;: Quelles sont les raisons objectives, logiques et non arbitraires d'utiliser des minuscules pour le premier mot de votre variable ou méthode de retour?

Modifier: pour MainMa

Remplacez ce code par le premier exemple de code dans votre réponse et voyez à quel point votre argument tient le coup:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
S'ils étaient en majuscules, quelqu'un d'autre demanderait pourquoi ils ne sont pas en minuscules ...
m3th0dman

11
ce ne serait pas bien si nos tout-puissants IDE pouvaient avoir un plugin qui mappait nos propres préférences personnelles pour des problèmes stylistiques comme celui-ci et nous permettait de les utiliser mais en coulisses, pour la "vraie version" du fichier source, appliqué la sémantique de style "projet". Il s'agit entièrement d'un problème visuel jusqu'à ce que vous ayez besoin de vérifier la version officielle du fichier. je rêve juste ...
Sassafras_wot

59
Malheureusement pour vous, la raison réelle et valable est "parce que c'est la norme". Il est avantageux pour les membres d'une même équipe de suivre la même norme de style de code. Si vous ne voyez pas pourquoi, alors vous devriez peut-être poser une autre question: "pourquoi les normes sont-elles utiles?"
Andres F.19

3
J'ai toujours supposé que les développeurs avaient opté pour camelCase parce qu'il avait l'air kewl. Il n'y a aucune raison «objective» pour camelCase elle - même au - dessus de PascalCase. Personnellement, je trouve que PascalCase (comme votre exemple) est beaucoup plus facile à lire et je l'utilise dans la plupart des endroits autres que JavaScript, où je conserve camelCase, donc je ne manquerai pas les invitations à des fêtes.
GrandmasterB

7
Recherche sur les avantages d'avoir un style de codage standard Peu importe vraiment ce qu'est la norme, juste qu'elle est suivie.
Mr.Mindor

Réponses:


88

Cette convention de dénomination est souvent utilisée lorsque les gens veulent pouvoir donner à une variable le même nom que son type. Par exemple:

Employee employee;

Certaines langues imposent même cette capitalisation. Cela évite d' avoir à utiliser des noms de variables comme ennuyeux MyEmployee, CurrentEmployee, EmployeeVar, etc. Vous pouvez toujours savoir si quelque chose est un type ou d' une variable, juste de la capitalisation. Cela évite la confusion dans des situations telles que:

employee.function(); // instance method
Employee.function(); // static method

De plus, en anglais, les noms ne sont généralement pas capitalisés, vous ne pouvez donc pas vraiment prétendre que votre capitalisation est «correcte».

Qu'est-ce que cela a à voir avec votre situation? Vous n'avez évidemment aucun problème à lire votre propre code, mais en gardant les choses aussi cohérentes que possible, vous réduisez la charge de travail mental de toute autre personne ayant besoin de lire votre code. En codant comme en écrivant, vous ajustez votre style en fonction des lecteurs.


1
Notez que le problème existe toujours dans le langage utilisé par l'OP, car les propriétés sont capitalisées (bien sûr, les propriétés peuvent être préfixées par this., ce qui évite la confusion; les variables locales ne peuvent pas avoir un tel préfixe).
Arseni Mourzenko

1
@oscilatingcretin, il s'appelle PascalCase.
Mr.Mindor

21
Employee Employeefonctionne, mais je dirai que c'est plus déroutant pour un lecteur humain que Employee employee. Ce dernier ressemble à deux choses différentes. Le premier ressemble à une répétition inutile.
Jamie F

14
@oscilatingcretin Exactement: "suppose que le lecteur comprend le cadre sous-jacent ..." J'aime lire JavaScript, Java, C #, C ++ et autres et traduire le code dans ma tête. Je n'aime pas avoir besoin de continuer à penser "Oh, le compilateur de ce langage peut gérer x ." alors que j'essaie juste de comprendre le code.
Jamie F

1
Notez que cela employee.function()pourrait également être une méthode statique, si le langage permet d'appeler des méthodes statiques à partir d'un objet (comme Java le fait). Le compilateur donne un avertissement, mais il est autorisé à le faire.
Uooo

34

Il n'y en a pas. C'est ce que font la plupart des gens, c'est donc devenu la norme parce que c'est ce que tout le monde fait. Beaucoup de littérature suit cette convention, donc les gens ont pris l'habitude.

La convention n'est pas aussi importante que la cohérence à travers le code. Tant que tout est nommé de manière cohérente afin que je puisse dire ce que les choses viennent de les regarder, peu importe que la première lettre soit en majuscule ou non.

Je trouverais choquant de trouver du code écrit à votre manière et je dirais que je ne l'aime pas. Mais c'est une question de style.

Maintenant, si vous le faites en milieu de travail, il serait préférable de coder dans le style de l'équipe afin que le code reste cohérent partout. Plutôt que d'avoir votre code différent de tout le monde.

http://thecodelesscode.com/case/94


3
J'aimerais que la plupart des programmeurs soient comme toi. Beaucoup sont douteusement passionnés et / ou dogmatiques à propos de la norme de boîtier que j'ai mentionnée.
oscilatingcretin

1
@Schieis c'est important si vous êtes le prochain programmeur à travailler sur le projet.
N4TKD

3
@oscilatingcretin Vous pourriez finir par être aussi passionné et / ou dogmatique une fois que vous aurez travaillé sur du code plein de var m_someVariableID = GetVariableValueId(). Surtout si vous devez le faire sans prise en charge de la saisie semi-automatique.
Tacroy

7
Si vous faites partie d'une équipe, il est important de suivre cette norme d'équipe. Notez, cependant, que de nombreux langages de programmation ont des normes de facto que vous devriez essayer de suivre, lors de la création d'un nouveau projet où l'équipe n'a pas de normes (ou où l'équipe vous a renvoyé de les définir). Si vous n'êtes pas sûr de la convention de codage à utiliser, suivre la convention utilisée par le fournisseur de la langue principale ou le cadre inclus est préférable à votre propre norme, sauf si vous pouvez justifier votre norme.
Brian

2
@Schleis bonne mise à jour, je ne suis pas d'accord, c'est juste une question de style, mais la convention et la convention deviennent une convention pour de bonnes raisons et doivent être suivies. Ce n'est pas une religion et un certain temps, vous devez très loin de la convention, mais vous devriez avoir une bonne raison.
N4TKD

25

1. Pourquoi la norme existe-t-elle?

Après tout, ne serait-il pas préférable de laisser tout le monde écrire le code selon ses préférences personnelles et d'arrêter de parler de la meilleure norme?

Le fait est que lorsque vous êtes habitué à un style, il est plus difficile de lire du code qui utilise un style différent. Votre cerveau passe plus de temps à essayer de comprendre la convention (s'il y en a), au lieu de comprendre ce que fait le code.

Quoi de plus lisible entre ces deux morceaux de code?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

ou:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Les deux morceaux de code s'exécutent de manière similaire. La seule différence est que dans le premier cas, chaque développeur qui a travaillé sur le projet a utilisé son propre style. Cela a rendu le code incohérent, illisible et dangereux. Le fait que les membres de l'équipe n'aient pas pu s'entendre sur la taille du retrait, couplé au fait que l'un d'entre eux refusait d'utiliser des accolades après chaque ifrendu le code extrêmement sujet aux erreurs: en le regardant, on peut croire que le second ifest exécuté uniquement lorsque le premier ifest vrai, ce qui n'est pas le cas.

Dans le second cas, tous les développeurs ont suivi le même standard. Certains d'entre eux étaient peut-être mécontents, car ils préféraient l'indentation à deux espaces ou parce qu'ils étaient habitués à des méthodes qui commencent par une petite lettre. Le fait est que le code est encore beaucoup plus lisible de cette façon, et le serait encore s'ils utilisaient une norme différente.

En ayant une norme stricte et uniforme, il facilite la lecture du code.

2. Pourquoi leur standard est meilleur que celui que j'ai inventé en ce moment?

Si une norme est utilisée par des centaines de milliers de développeurs dans le monde, respectez-la. N'inventez pas le vôtre: même si c'est mieux, il est plus facile pour vous de migrer vers le standard mondial plutôt que vers ces centaines de milliers de développeurs pour commencer à utiliser le vôtre.

Exemple: dans ma propre entreprise, j'ai une convention spécifique pour nommer les clés primaires et étrangères et les index dans la base de données. Ces noms ressemblent à:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] ou
  • [PK for RoleOfPassword: RoleId, PasswordId].

Personnellement, je trouve cette convention excellente et extrêmement claire. Pour moi. Mais ça craint totalement. Ça craint, parce que c'est le mien, et parce qu'aucun des milliers d'administrateurs de base de données ne l'a jamais utilisé. Cela signifie que:

  • Quand j'engagerai un DBA, il sera forcé d'apprendre la nouvelle convention, au lieu de commencer son travail maintenant,

  • Je ne peux pas partager de code sur Internet tel quel: ces noms étranges perturberont les gens qui liront mon code,

  • Si je prends du code de l'extérieur pour l'utiliser dans le mien, je serais obligé de modifier les noms pour le rendre uniforme,

  • Si un jour je décide d'utiliser un standard bien connu, je serai obligé d'aller modifier chacun des quelques centaines de noms.

3. Et la capitalisation?

Les propriétés ont une portée ou une visibilité plus grande que les champs ou les variables locales. Faire commencer les propriétés par une majuscule, des champs et des variables - avec une petite va dans ce sens.

Si vous considérez C #, cette logique est suffisamment cohérente.

Si vous considérez Java, les méthodes commencent par de petites lettres, qui ne suivent pas la logique.

Donc non, il n'y a aucune preuve définitive que cette convention est meilleure que la vôtre. C'est juste que celui-ci est utilisé à l'échelle mondiale, et le vôtre ne l'est pas. Rien de mieux .

En JavaScript, les fonctions commencent par une petite lettre, sauf si elles nécessitent un newavant elles. Ne serait-ce pas mieux dans l'autre sens? Peut être. Le fait est que pendant des années, les développeurs JavaScript ont utilisé ce standard, et non l'inverse. Réécrire chaque livre et forcer chaque développeur à changer de style maintenant serait un peu compliqué.


1
Quant à la partie sur le code étant moins lisible car il suit un standard légèrement différent, je n'ai jamais eu ce problème. À moins que les variables de quelqu'un ne soient nommées comme hookyDookyDoo, aucune convention de dénomination ou de casse ne nuit à la lisibilité. Aussi, gardez à l'esprit que je ne dis pas que ma convention est "meilleure" car elle n'apporte vraiment rien de spécial à la table de développement. Enfin, je ne comprends pas votre point de vue [Les propriétés ont une portée plus large ... va dans ce sens] . Qu'est-ce que la portée a à voir avec la convention de casse? Allez dans quelle direction?
oscilatingcretin

23
@oscilatingcretin, la question n'est pas de savoir si vous avez déjà eu ce problème, c'est de savoir si vos collègues l' ont fait. De toute évidence, ils l'ont fait ou ils ne se plaindraient pas.
Karl Bielefeldt

1
Re: your edit: votre premier exemple de code montre simplement un code mal construit, sujet aux catastrophes. Mon PO ne concerne pas un code mal construit et sujet aux catastrophes. Il s'agit du même code exact que votre deuxième exemple, mais d'une convention de casse différente. J'ai édité votre deuxième exemple de code et l'ai publié dans mon OP avec ma convention de casse. Remplacez-le par votre premier exemple de code, s'il vous plaît.
oscilatingcretin

5
@oscilatingcretin: Le premier exemple de code montre non pas du code mal construit, mais du code écrit par une équipe où chaque développeur a suivi son propre style. Cela se produit avec trop de bases de code, avec suffisamment de temps (par exemple cinq ans). Remarque: avez-vous manqué le: "Le fait est que le code est encore beaucoup plus lisible de cette façon, et le serait encore s'ils utilisaient une norme différente." ?
Arseni Mourzenko

6
@oscilatingcretin De nombreuses recherches montrent que la cohérence diminue considérablement l'effort cognitif requis pour comprendre quelque chose que vous lisez. Pour une prose régulière, une mauvaise orthographe, une mauvaise ponctuation et une grammaire moche, il est plus difficile pour quelqu'un de lire - qu'il le remarque consciemment ou non. Le code est assez difficile à lire, sans le rendre plus difficile - le respect de la "norme commune" (pour votre pile technologique de choix) augmente la cohérence globale et libère les neurones pour se concentrer sur les activités importantes de ce que fait le code, plutôt que sur la façon dont il est écrit.
Bevan

10

Techniquement, cela n'a pas d'importance (ou du moins, dans la plupart des langues, cela n'a pas d'importance).

Cependant, la plupart des communautés de programmation (qu'il s'agisse de communautés mondiales qui se sont formées autour d'une langue particulière, de sous-groupes de ces communautés, de groupes qui se sont formés autour d'une bibliothèque ou d'une boîte à outils populaire ou simplement d'équipes individuelles) ont développé des normes de codage établies. Les détails exacts sont relativement peu importants (bien que dans de nombreux cas, un bon argument puisse être avancé pour eux), ce qui est important est que vous vous y teniez.

Non pas parce qu'ils sont les meilleurs, mais parce qu'ils sont ce que tout le monde utilise; si vous respectez la norme, votre code sera cohérent avec la plupart des autres codes que vous finirez par utiliser - bibliothèques, code des coéquipiers, langage intégré. La dénomination cohérente est une arme de productivité puissante, car cela signifie que lorsque vous devinez le nom de quelque chose, vous devinerez généralement bien. Est - ce file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? La convention de dénomination vous le dira.

Porter vos préférences personnelles dans chaque langue que vous rencontrez est particulièrement dangereux, car tout d'abord, chaque langue a sa propre culture, et les conventions de dénomination sont souvent incompatibles; et deuxièmement, il existe de nombreuses différences subtiles entre les langues en ce qui concerne la dénomination.

Un seul exemple: en C #, les types et les variables vivent dans des espaces de noms séparés; le compilateur est assez intelligent pour connaître la différence. En C, cependant, les deux types de noms partagent un espace de noms, vous ne pouvez donc pas avoir un type et une variable du même nom dans la même étendue. Pour cette raison, C a besoin d'une convention de dénomination qui distingue les types des variables, contrairement à C #.


Il semble donc vraiment que certaines langues plus anciennes ont ouvert la voie à des normes de codage pour les langues futures (comme votre exemple C / C #). C'est d'autant plus regrettable que le fait de devoir suivre la façon de caser les variables et les membres d'objet ajoute simplement un niveau de complexité inutile qui peut être fait sans.
oscilatingcretin

4
@oscilatingcretin Lorsque tout le monde utilise la même convention, cela n'ajoute pas de complexité continue, la convention devient une partie de votre modèle mental pour la langue en question ET facilite l'utilisation de cette langue. Ceci est démontrable et mesurable.
Mr.Mindor

J'allais vous voter mais vous dites d'abord que cela n'a pas d'importance, puis vous écrivez plusieurs paragraphes expliquant pourquoi cela compte. Si vous supprimez "ça n'a pas d'importance" au début, je vous voterai.
Tulains Córdova

10

Je suis surpris que personne d'autre n'ait dit cela, mais je pense que la différence de capitalisation est incroyablement utile pour une raison: c'est agréable et pratique de pouvoir savoir si une variable est uniquement portée localement ou non. Si la variable est locale, je ne m'inquiète pas autant des effets secondaires de sa modification, comme la refactorisation du nom. J'aime donc une convention qui distingue les membres de la classe des variables de classe privées des variables locales.

Avec Intellisense moderne, cela importe de moins en moins, mais cela me donne quand même quelques repères lorsque je lis du code pour savoir où je dois chercher pour trouver la définition.

Et une bonne partie de cela peut être laissée par mon pire style il y a des années, lorsque les méthodes n'étaient pas aussi susceptibles de tenir sur un seul écran.


Un certain nombre de projets sur lesquels j'ai travaillé spécifient quelque chose comme ça dans leur guide de style.
anaximander

7

Cela ressemble plus à une question de conventions qu'à votre convention spécifique.

Pour chaque convention que vous rompez, vous ajoutez simplement plus de travail pour tout le monde. Peut-être que dans un monde parfait, toute l'entreprise travaille sur un seul produit toute sa vie ... mais en réalité, ce n'est pas vrai. Les gens sautent entre les projets, parfois entre les entreprises ou même pour le plaisir. Plus le code est aléatoire, plus il est difficile et coûteux de travailler. En tant que propriétaire d'entreprise ou partie prenante, je ne voudrais pas embaucher des développeurs qui pensent de manière égoïste plutôt que pour le bien du projet.

Cela se résume au professionnalisme: parfois, nous devons mettre de côté nos styles personnels et aller avec ce qui est plus efficace pour une adoption de masse. Cela encourage la collaboration et supprime les barrières étrangères qui ne devraient pas être là en premier lieu.

Quant à votre convention actuelle, CapitalCamelCase est généralement réservé aux noms de classe (ou en Javascript, constructeurs). Si je vois une variable en majuscule, une supposition éclairée dictera que je devrai l'instancier pour l'utiliser. Si c'est faux, je vais être énervé que le code ne respecte pas les normes de la communauté. Même avec la plupart des autres langues, tout le monde qui le regarde pour la première fois est immédiatement induit en erreur. Je veux que le code soit évident, pas trompeur.


"Si je vois une variable en majuscule, une supposition éclairée dictera que je devrai l'instancier pour l'utiliser." Je ne comprends pas. Comment le fait de voir une variable en majuscule vous fait-il penser que vous devez l'instancier avant de l'utiliser? Parce qu'il ressemble à un nom de classe? Vous ne connaissez donc pas la différence entre MyClass MyClass = nullet class MyClass { }?
oscilatingcretin

3
Oui, je vois la différence. La convention existe pour éviter toute ambiguïté. var car = new Car();Selon ma dernière ligne - pourquoi ne pas le rendre évident?
Adrian Schneider

3
@oscilatingcretin Il y a bien sûr une différence. Mais le cerveau humain bénéficie d'indices visuels dont un analyseur informatique n'a pas besoin. Il semble que vous remettiez en question la nécessité de conventions / normes ... ce qui est une question valide, bien que différente de ce que vous aviez initialement demandé.
Andres F.19

2

"car la casse complète doit être réservée aux propriétés et aux méthodes void. Les variables locales et les méthodes qui renvoient une valeur doivent avoir le premier mot en minuscules" et parce que c'est la convention standard.

D'autres programmeurs récupèrent votre code en ce moment et pensent que c'est une propriété et c'est vraiment une variable locale, ce qui rend leur travail plus difficile.


1
Avez-vous lu ma question en entier? Jetez un coup d'œil vers la fin où j'ai dit:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin

8
Oui et oui c'est important, le prochain programmeur ne devrait jamais avoir besoin de penser NuggetCount, vous devriez pouvoir regarder le nom et le dire. Un bon livre à lire est "Clean Code", vous devriez pouvoir lire le code comme une histoire et savoir ce qui se passe.
N4TKD

2
@oscilatingcretin Je pense que la frustration que vous voyez avec des personnes répondant à des questions légèrement différentes de celles que vous posez est la preuve de la confusion qui peut être générée lorsque vous violez les conventions acceptées.
Mr.Mindor

7
Les conventions ont un sens. Si, selon la convention, NuggetCount implique une propriété, cela signifie qu'elle a une portée au-delà de ce qu'aurait une variable locale. Ce qui signifie que je dois rechercher davantage pour déterminer cette portée. Je dois déterminer: y a-t-il des effets secondaires pour le changer? Puis-je faire confiance à sa valeur pour qu'elle ne soit pas modifiée par un autre thread pendant que je l'utilise? nuggetCount implique une portée locale et je devrais pouvoir supposer que toute son histoire est locale.
Mr.Mindor

5
@oscilatingcretin OUI! Exactement! J'avais confiance que ce qu'ils avaient écrit suivait la convention et emportait tout ce qui allait avec. Je croyais qu'ils travaillaient dans le cadre de l'équipe et je pouvais profiter des avantages de l'utilisation de cette convention (sachant ce que nuggetCount était en un coup d'œil). Si ce n'est pas le cas, je fais probablement ce que vos collègues ont fait: j'essaie d'éduquer le responsable , et je perds plus de temps la prochaine fois que je dois les suivre en ne faisant pas confiance. En ne respectant pas la convention, ils ont produit un code moins lisible et moins facile à gérer. Avez-vous une raison de vouloir contrevenir à la convention?
Mr.Mindor

0

Comme d'autres l'ont dit, aucune raison réelle, sauf pour obtenir une convention de dénomination. Si vous pouvez mettre toute votre équipe sur la même page, vous pouvez probablement vous faire gagner du temps. Par exemple, personnellement, j'ai commencé un truc de normes de codage qui est entré dans cela et nous avons utilisé camelCase pour tous les varials privés ainsi que les choses passées par Val, alors que nous avons utilisé PascalCase pour les choses qui sont publiques ainsi que les choses passées par Ref.

Les lignes deviennent un peu floues lorsqu'il s'agit de choses comme protégé ou Out ou quelque chose.


-2

Le langage (avec son aspect formel et conventionnel) est important pour organiser vos pensées, il a le pouvoir sur vos façons de penser. Donc, c'est juste une douleur de passer d'un style à un autre.

Les symboles minuscules et majuscules ont de grandes différences sémantiques dans Haskell, ils diffèrent également légèrement dans Scala et je les ai utilisés tous les deux. Les autres langues que j'utilise ne font aucune différence entre ces deux types d'identifiants, mais garder les pensées dans la façon dont Haskell perçoit les identifiants est beaucoup plus facile pour moi que de fragmenter mon esprit pour différentes langues.


-2

Pour moi, cela revient à l'attente.

Quand je lis la plupart du code, je m'attends à ce que tout ce qui commence par a lowerCasesoit une variable locale ou une fonction (en C # qui ne serait qu'une variable). Si je vois une variable locale dans ProperCase, je trébucherais probablement et serais confus pendant un certain temps, pensant que c'est soit un nom de classe, soit une propriété, soit autre chose. Cela me ferait relire le code et m'ennuierait.

C'est probablement ce qui se passe dans votre cas.

De plus, il est pratique de pouvoir dire quel rôle joue une variable simplement en regardant la première lettre, et cela évite les conflits entre un nom d'instance et un nom de classe.


-3

Les minuscules doivent être utilisées pour les variables locales pour faciliter la saisie (touche vitesse / pas de décalage). Les majuscules sont utilisées pour améliorer la lisibilité en séparant les mots dans un nom. Le code avec des noms de variables locales d'un seul mot (qui devraient être communs) est rapide et facile à taper. L'utilisation de majuscules pour chaque nouveau mot du nom est également plus rapide (et moins d'espace) que l'utilisation de traits de soulignement qui ajoutent un autre caractère - cela est également connu sous le nom de casse de chameau.


Je pense que c'est une très bonne réponse et je ne comprends pas les votes négatifs. C'est une réponse logique - basée sur des faits comme l'a demandé le PO. Si vous votez contre, veuillez vous expliquer. La touche Maj enfoncée partout est massive. Pensez-y, presque chaque mot que vous tapez dans votre code démarrera PascalCase et pour chacun, vous aurez besoin d'une autre touche Maj enfoncée. Si vous voulez être minimaliste et efficace, il est logique de supprimer les pressions inutiles sur les touches Maj. Et logiquement, vous voudriez être plus productif, ce qui signifie que lorsque je me tiens, vous appuyez sur moins de touches. Pourquoi appuyer davantage?
AIon

-3

Je suis d'accord avec l'OP ici. camelCase semble juste faux. Je suis également d'accord avec le fait qu'il s'agit de la norme et que nous devons nous en tenir à la même norme ou à quoi sert d'avoir une norme. Il est également logique que PascalCaps soit utilisé pour les méthodes, etc. et camelCase pour vos propres variables, etc. comme moyen de différenciation lorsque vous n'utilisez pas un IDE qui colore les méthodes pour vous.

Pour le contourner, je préfixe toujours les noms de mon objet avec le type d'objet qu'il est. Donc, s'il s'agit d'une variable chaîne, j'appelle strMyVariable. S'il s'agit d'une sorte d'objet, je l'appelle objMyObject, etc.


3
cela ne semble pas offrir quoi que ce soit de substantiel par rapport aux points avancés et expliqués dans les 11 réponses précédentes
gnat
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.