Quelle est la raison d'utiliser des minuscules pour le premier mot dans 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 type utilisera employeeCount pour un 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. Ce dernier vraiment brouille les jimmies des gens.
La raison typique donnée pourquoi 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 juste une réponse arbitraire de qui est la norme . Quelle que soit la réponse, cela se résume généralement à C'est exactement 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 tous les nuggets. SetNuggetCount(x) suggère que vous affectez une nouvelle valeur au nombre de nuggets. NuggetCount suggère à lui seul 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 IS IL?" ça compte vraiment? "
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 ennuyeux comme MyEmployee, CurrentEmployee, EmployeeVar, etc. Vous pouvez toujours dire si quelque chose est un type ou une variable, juste à partir 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 faites cela sur le lieu 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.
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 de cesser 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 if a rendu le code extrêmement sujet aux erreurs: en le regardant, nous peut croire que le second if n'est exécuté que lorsque le premier if est 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 aux 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 norme est meilleure que celle [~ # ~] i [~ # ~] 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. Aucun n'est meilleur .
En JavaScript, les fonctions commencent par une petite lettre, sauf si elles nécessitent un new avant 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 vous en tenez à 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, tandis 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ées ou Out ou quelque chose.