Boîtier Pascal ou Camel Casing pour le code C #?
Je me suis disputé avec mes collègues sur le boîtier Pascal (cas de chameau supérieur) contre inférieur CamelCasing . Ils sont utilisés pour réduire le boîtier de chameau pour tout, des noms de table dans les bases de données SQL à la dénomination des propriétés en code C #, mais j'aime mieux le boîtier Pascal, le boîtier de chameau inférieur pour les variables et le boîtier Pascal pour les propriétés:
string firstName;
public string FirstName {
...
}
Mais ils y sont habitués:
string _firstname;
public string firstName {
...
}
J'essaie de suivre leur "standard" pour que le code soit le même mais je n'aime pas ça.
J'ai vu qu'au moins le framework .NET utilise cette convention et c'est ainsi que j'essaie de conserver mon code, par exemple:
System.Console.WriteLine("string")
Qu'utilisez-vous/préférez-vous et pourquoi? Je suis désolé si quelqu'un d'autre a posé cette question mais j'ai cherché et je n'ai rien trouvé.
Mise à jour: J'ai donné un exemple de méthode et non une propriété mais c'est la même chose. Comme je l'ai indiqué dans le premier paragraphe, mes collègues utilisent la convention Pascal pour tout (variables, méthodes, noms de table, etc.)
J'utilise ce que le Framework utilise, car c'est la meilleure pratique de facto. Cependant, tant que le code de votre entreprise utilise de manière cohérente leur style, il vaut mieux s'y habituer. Si chaque développeur a sa propre norme, il n'y a pas de norme du tout.
Un lien vers l'officiel directives de conception pourrait aider. Plus précisément, lisez la section sur Styles de capitalisation .
Dans le grand schéma des choses, Pascal vs Camel n'a pas beaucoup d'importance et vous ne convaincrez personne de revenir sur une base de code existante juste pour changer la casse des noms. Ce qui est vraiment important, c'est que vous vouliez être cohérent dans une base de code donnée.
Je suis juste content tant que vous n'utilisez pas le hongrois.
Vous devriez jeter un œil au nouvel outil de Microsoft, StyleCop pour vérifier le code source C #. Gardez également un œil sur FxCop pour vérifier les assemblys .Net compilés. FxCop se concentre davantage sur les détails de ce que fait le code, pas sur la mise en page, mais il a quelques règles de dénomination liées aux noms publiquement visibles.
StyleCop définit une norme de codage, qui est désormais promue par Microsoft en tant que norme industrielle. Il vérifie le code source C # par rapport à la norme. StyleCop adhère à votre style PascalCase.
Obtenir des gens sur StyleCop (ou toute autre norme d'ailleurs) peut être difficile, c'est tout un obstacle, et StyleCop est assez exhaustif. Mais le code doit être conforme à une norme uniforme - et une norme personnelle vaut mieux qu’aucune, une norme d’entreprise est meilleure qu’une norme personnelle, et une norme industrielle est la meilleure de toutes.
Il est beaucoup plus facile de convaincre les gens quand un projet démarre - l'équipe est en cours de formation et il n'y a pas de code à convertir. Et vous pouvez mettre en place des outils (FxCop, StyleCop) pour interrompre la construction si le code ne répond pas aux normes.
Vous devez utiliser la norme pour le langage et le framework - le code SQL doit utiliser les normes SQL et le code C # doit utiliser les normes C #.
Pour les interfaces publiques, vous devez vous en tenir aux directives de conception du framework MS .NET: " Conventions de capitalisation ".
Pour les membres non exposés, tout ce que vous et vos collègues pouvez convenir.
Je (et mon équipe) préfère réserver les majuscules initiales aux noms de classe.
Pourquoi? Java normes se propageant, je pense.
Je viens de trouver Coding Standards for .Net .
À partir du Guide du développeur .NET Framework Conventions de capitalisation , Respect de la casse:
Les directives de capitalisation existent uniquement pour faciliter la lecture et la reconnaissance des identifiants. Le boîtier ne peut pas être utilisé pour éviter les collisions de noms entre les éléments de la bibliothèque.
Ne présumez pas que tous les langages de programmation sont sensibles à la casse. Ils ne sont pas. Les noms ne peuvent pas différer uniquement par cas.
Le boîtier Pascal doit être utilisé pour les propriétés. En ce qui concerne les noms variables, certaines personnes utilisent _ et certains poeple utilisent m_ et certaines personnes utilisent simplement une vieille carcasse de chameau. Je pense que tant que vous êtes cohérent ici, cela ne devrait pas avoir d'importance.
Cet exemple de .NET que vous avez publié était une fonction. Le "standard" adopté pour les méthodes/fonctions est un cas de chameau plafonné (ou Pascal, si vous voulez l'appeler ainsi).
Je m'en tiens au chameau où je peux. Il vous permet de connaître facilement la différence entre une variable et une méthode.
De plus, je suis fan de coller un trait de soulignement devant les variables de classe locales. Par exemple.: _localVar.
Je suppose que vous devez accepter ce que dit la norme de codage pour votre lieu de travail, même si vous ne l'aimez pas personnellement. Peut-être qu'un jour à l'avenir, vous pourrez dicter vos propres normes de codage.
Personnellement, j'aime que les bases de données utilisent des noms de la forme "fish_name", "tank_id", etc. pour les tables et les champs, tandis que l'équivalent de code du modèle de base de données serait "fishName" et "tankID". Je n'aime pas non plus les noms "_fooname" lorsque "fooName" est disponible. Mais je dois répéter que c'est subjectif, et différentes personnes auront des idées différentes sur ce qui est bon et mauvais en raison de leur expérience et de leur éducation antérieures.
En fait, il n'y a pas de convention "standard" à ce sujet. Il y a une directive éditée par Microsoft quelque part, et comme avec toute autre directive de convention de dénomination, il y en a sûrement une autre qui la réfute, mais voici ce que j'ai compris comme "convention de casse C # standard".
- PerWordCaps dans les noms de types (classes, énumérations), constantes et propriétés.
- camelCase pour les variables locales très longues et les variables protégées/privées
- Aucun ALL_CAPS jamais (enfin, seulement dans les définitions du compilateur, mais pas dans votre code)
- Il semble que certaines des classes système utilisent des noms soulignés (_name) pour les variables privées, mais je suppose que cela vient de l'arrière-plan de l'auteur d'origine car la plupart d'entre elles provenaient directement de C++. Notez également que VB.NET n'est pas sensible à la casse, vous ne pourrez donc pas accéder aux variables protégées si vous étendez la classe.
En fait, FxCop appliquera quelques-unes de ces règles, mais (AFAIK) il ignore l'orthographe que vous utilisez pour les variables locales.
J'aime les conventions de codage énoncées dans les spécifications du projet Aardvark'd