Deux conventions de nommage C #: qu'en pensez-vous? [fermé]

https://stackoverflow.com/questions/823294

05-07-2019
|

Question

J'ai deux conventions de codage spécifiques C # que je pratique avec des sentiments mitigés. Je serais curieux d'entendre ce que les gens pensent. Ils sont:

# 1. Nommez des instances après la classe dont il s'agit, camelCased

# 2: "Noms de propriétés correspondants"

Voici le raisonnement:

# 1. Nommez des instances après la classe dont il s'agit, camelCased

J'utilise ceci comme paramètre par défaut pour la convention de nommage. Bien sûr, il y a des exceptions. Mais utilisé de manière cohérente, il améliore radicalement améliore la clarté du code et sa facilité de maintenance. Le code ressemble à ceci:

var dataConnection = new DataConnection();
//not: var dataConn, dbConn, sqlConn, myDbPickOfTheDay etc.

FileInfo fileInfo = new FileInfo();

Timer timer = new Timer(); 

//etc.

Je suis au point où un code comme celui-ci me cause une douleur physique:

DataConnection dbConn = new DataConnection();

Je ne saurais trop insister sur le fait que cette convention a dissipé la douleur et la colère du jeu du nom de variable.

Cette convention contraste nettement avec la tentative de nommer les éléments de manière à indiquer ce que fait l’instance, ce qui revient à essayer d’incorporer de manière créative l’analyse de rentabilité dans le code. Le code a un moyen de se refactoriser au point où ces noms originaux sont au mieux trompeurs.

Pour moi, cette convention est de l’or. Cela empêche également la pratique horrible de noms de variables légèrement modifiés pour la même chose.

Voici un exemple de cette convention:

class Person { ...
   public string FirstName { get; set; }

//and then
var person = new Person();
person.FirstName = firstName; //where firstName comes from somewhere else.

Très facile à lire. Très ennuyeux. Il est bon d’ennuyer pour maintenir le code.

Cependant , cette convention m'amène au n ° 2:

# 2 "Noms de propriétés correspondants" (faute d'un meilleur titre)

Voici un exemple:

public class ShoppingCart { ..
  private Item item;
  public Item Item {  //<---- ?
  get { return this.item; } ...

Le compilateur est parfaitement satisfait de cela. Et, en fait, il expose une très belle interface:

//notice how tempting it is to just say "ShoppingCart cart ... "
ShoppingCart shoppingCart = new ShoppingCart();  
shoppingCart.Item = item;

Maintenant, l’alternative consiste à être créatif - vous devez en fait créer deux bons noms de variable pour Item: le nom de la propriété publique et le nom de la variable membre privé.

Combien de fois avez-vous vu cela et souhaitez-vous prendre votre retraite immédiatement?

 public class ShoppingCart { ..
      private Item cartItem;
      public Item ShoppingCartItem { 
      get { return this.cartItem; } ..
  ///....
  ShoppingCart userShoppingCart = new ShoppingCart();
  userShoppingCart.ShoppingCartItem = userSelection;

Je suis assez convaincu par la convention # 1 avec laquelle je pense pouvoir vivre avec # 2.

Qu'en pensez-vous?

La solution

au cas où vous ne le sauriez pas et si cela vous importe, C # a déjà une norme de dénomination

http://msdn.microsoft.com/en -us / library / xzf533w0 (VS.71) .aspx

De plus, revoyez vos conventions ... voici quelques suggestions supplémentaires.

fileInfo a belle allure à côté de FileInfo mais il n’a pas de signification autre que le type que je peux obtenir rapidement en passant la souris sur le type ou dans intellisense. Je suggérerais de nommer vos variables avec une signification et un contexte si elles sont disponibles. remoteWebServerLog, localWebServerLog ou même localWebServerLogFileInfo si vous aimez le type dans le nom.

Si je peux écarter tout conseil de revenir au code, vous avez écrit 6+ mois plus tard. Vous allez vous gratter la tête pour essayer de comprendre ce que sont tous vos dbConn et fileInfo. Quel fichier? Quelle db? De nombreuses applications ont plusieurs dbs, s'agit-il de dbConn à OrdersDB ou à ShoppingCartDB?
La dénomination de classe devrait être plus descriptive. Je préférerais ShoppingCartItem à Item. Si chaque ListBox, DropDown, etc., a nommé ses éléments de collection, "Article". vous entreriez en collision avec de nombreux espaces de noms et seriez obligé de nettoyer votre code avec MyNameSpace.ShoppingCart.Item.

Cela dit ... même après des années de codage, je me trompe toujours et je ne respecte pas les règles 100% du temps. J’aurais peut-être même utilisé FileInfo fi = ... mais c’est pourquoi j’adore mon Resharper " Refactor- & Renommer " commande et je l'utilise souvent.

Autres conseils

La Convention n ° 1 peut devenir déroutante. Si vous aviez deux objets FileInfo dans la même méthode (disons une source et une cible), vous devrez vous écarter de la convention pour les nommer.

Les noms de variables doivent être mnémoniques - pour indiquer à l’observateur occasionnel l’intention de les utiliser.

Peut-être seriez-vous plus heureux de combiner les deux conventions ... telles que sourceFileInfo et targetFileInfo, selon cet exemple.

Évidemment, vous ne pouvez pas nommer tous les System.String de votre projet string *, , mais pour des choses que vous n'utilisez pas beaucoup, en particulier. choses dont vous n’avez besoin que d’une seule et dont la fonction dans votre code est évidente par son nom, ces conventions de dénomination sont parfaitement acceptables.

Ils sont ce que je fais, de toute façon.

Je choisirais un nom plus spécifique pour, par exemple, l'objet Timer. A quoi sert une minuterie? Mais je nommerais certainement un DataConnection DataConnection.

* Même si " chaîne " n'était pas un mot clé ...

Je fais tout le temps 1 et je le trouve très lisible. Je suis sur la clôture avec 2. Je trouve cela déroutant dans certaines situations, principalement parce qu'il est difficile de distinguer le type de la propriété en raison des identifiants identiques.

Je suivrais normalement la convention n ° 1, bien que pour les noms de classe longs, j'ai tendance à n'utiliser que les initiales de la classe. Si je fais référence à plusieurs objets du même type, le nom du type doit être précédé d’un nom indiquant de quel nom il est ou à quoi il sert.

J'utilise assez souvent la convention n ° 2 si cela a du sens. Il n'y a rien de pire que d'avoir l'exemple de cart.ShopingCartItem que vous avez cité, le fait même qu'il s'agisse d'une propriété de ShoppingCart rend cette partie du nom de la propriété totalement redondante. Cependant, il est fort probable que j'appelle la classe ShoppingCartItem et l'élément property. L'article correspond à un nom trop générique alors que ShoppingCartItem vous indique le type d'article avec lequel vous travaillez.

Je suis la convention 1 tout le temps. Toutefois, j’ajoute un qualificatif supplémentaire s’il existe deux objets côte à côte.

Cela dit, rendre cette convention obligatoire peut être problématique:

Dans un certain contexte, panier peut être un nom suffisant pour un objet ShoppingCart (si, par exemple, il n'y a pas d'autre 'panier' dans la même fonction être confondu avec).
Parfois, la convention peut complètement occulter l'objectif de l'objet déclaré. Par exemple, Window scoreBoard = new Window () indique que nous avons un objet qui est effectivement une fenêtre mais qui est utilisé comme scoreBoard. Très expressif. Mais après la convention 1, vous devriez écrire Fenêtre fenêtre = nouvelle Fenêtre () qui cache totalement l’intention derrière cette fenêtre.

Je dirais donc que vous devez utiliser cette idée de nommage partout sauf si elle gêne le sens ou semble excessivement exigeante.

À propos de la convention 2, je suis tout à fait d’accord. Garder les noms de propriété succincts et laisser le nom de l'objet compléter la signification de son invocation est une chose élégante. Cela fonctionne parfaitement avec des objets bien nommés. Il y a donc peu de raisons d'être timide pour l'utiliser.

Je n'aime pas du tout la notion d'avoir plusieurs identificateurs de portée qui ne diffèrent que par leur utilisation des majuscules / minuscules; si j'avais mes commandes, le code utilisant un identifiant serait obligé d'utiliser la même combinaison de lettres majuscules / minuscules que sa déclaration, mais le code ne serait pas autorisé à déclarer deux identificateurs de la même portée qui ne diffèrent que par cas, ni d'accès tout identifiant qui - sauf pour la casse - correspondrait à un identifiant dans une portée interne. Bien qu'aucun langage que je connaisse (certainement pas VB ni C #) n'applique de telles règles, le code rédigé conformément à ces règles pourrait être librement transférable entre langages sensibles à la casse et non sensibles à la casse sans devoir renommer les identificateurs.

En conséquence, je n'aime pas le motif n ° 2. La conformité CLS exige que tous les identificateurs de ce style soient limités à la portée private ou interne . Etant donné que vb.net et C # permettent aux noms de commencer par des traits de soulignement, si une propriété est nommée Trait , je ne vois aucune raison de préférer trait à _trait . L’utilisation de ce dernier nom permet de distinguer clairement les cas où le programmeur souhaite écrire dans la variable de support de ceux où son doigt a glissé sur la touche Maj.

En ce qui concerne le motif n ° 1, dans les cas où l'objectif d'un type ou d'une méthode est résolu autour d'un seul objet encapsulé d'un type particulier, je préfère préfixer les champs avec mon ou les paramètres avec le . Même dans les cas où le compilateur autoriserait l’utilisation des mêmes noms pour les membres et les paramètres de l’instance, l’utilisation de préfixes distincts évite la possibilité d’utiliser accidentellement l’un lorsque l’autre est requis.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow