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

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

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.

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

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

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

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.

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.

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

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.

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.

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.

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