Langage C#
  1. Langage C#
  3. Pourquoi devrais-je marquer les variables privées comme étant privées si elles le sont déjà?
Intereting Posts
Collisions d’espace de noms TypeInitializationException levée pour la classe Program Erreur lors de la tentative d’exécution bitwise non (~) sur un UInt16 en C # POST HTTP simple dans Windows Phone 8 Ouvrez Form2 à partir de Form1, fermez Form1 à partir de Form2 Envoi d’une chaîne telle que JSON de C # à javascript Lequel utiliser: Algorithmes de hachage gérés et non gérés Filestream ne lit que les 4 premiers caractères du fichier Référence dynamic aux fichiers de ressources en C # Serveur / client communicant à deux voies? Qu’est-ce qui ne va pas avec «DataContext = this» dans les contrôles utilisateur WPF? Pouvons-nous convertir le type anonyme en liste en utilisant Linq en entité en C #? Silverlight ListBox avec ObservableCollection et filtre dynamic Regex recherche et remplace où le remplacement est un mod du terme recherché dans linq pourquoi les appels ultérieurs de IEnumerable.Intersect sont-ils beaucoup plus rapides

Pourquoi devrais-je marquer les variables privées comme étant privées si elles le sont déjà?

Autant que je sache, en C #, tous les champs sont privés par défaut, sauf indication contraire. 

class Foo { private ssortingng bar; } class Foo { ssortingng bar; }

Je suppose que ces deux déclarations sont égales.

Ma question est donc la suivante: pourquoi devrais-je marquer des variables private comme étant private si elles sont déjà privées?

Je suis sur la barrière depuis un moment à ce sujet. J’avais l’habitude de plaider pour que ce soit implicite, mais je pense maintenant que je suis enclin à le rendre explicite.

Raisons pour laisser cela implicite:

  • Cela signifie qu’il y a une plus grande différence pour les membres non privés (ou tout ce qui a plus d’access que le nombre par défaut); cela met en évidence la différence lors de la lecture du code

Raisons pour le rendre explicite:

  • Certains développeurs peuvent ne pas connaître les valeurs par défaut: le rendre explicite signifie qu’il est clair pour tout le monde
  • Cela montre que vous avez activement pris une décision, plutôt que de vous contenter de la valeur par défaut

Ces derniers points sont essentiellement ceux d’Eric Lippert lorsque nous en avons discuté il y a quelque temps.

À présent; les champs devraient toujours être pratiquement privés de toute façon, il est donc préférable de ne pas vous déranger.

Pour le sujet plus large, je me souviens d’un commentaire d’Eric Lippert, qui disait essentiellement que, compte tenu d’une méthode / classe / peu importe: 

 void Foo() {} class Bar {}

Ensuite, il n’est pas clair s’ils sont délibérément privés / internes, ou si le développeur a réfléchi à la question et a décidé qu’ils devraient être privés / internes / peu importe. Ainsi, sa suggestion était: dites au lecteur que vous faites les choses délibérément plutôt que par accident – expliquez-le.

Oui, ils sont égaux, mais j’aime bien marquer les variables privées comme étant privées . Je pense que cela améliore la lecture.

J’utilise aussi cette notation commune pour les membres privés, elle est très utile: 

 private ssortingng _bar;

C’est purement une question de normes de codage mais, pour ce que cela vaut, je marque toujours explicitement les membres privés comme des membres privés.

Si vous permutiez régulièrement entre Java et C #, j’imagine qu’il serait assez important de spécifier explicitement le modificateur d’access. Par exemple en Java 

 void myMethod() { }

toute classe de votre paquet a access à cette méthode. En C #, c’est évidemment privé à la classe et aux classes internes.

Ne laissez pas les gens deviner, ne les laissez pas émettre de fausses suppositions et ne pensez pas que moins de caractères équivaut en aucune façon à la clarté.

Il n’y a pas de bonne raison de ne pas l’ expliciter, et c’est une erreur de la part de C # de la prendre en charge (surtout s’ils sont disposés à faire ce qu’ils ont fait pour changer d’énoncé pour la même raison)

L’utilisation explicite de private peut améliorer la lisibilité dans certains cas d’extrémité.

Exemple: 

  /* Tomorrow when we wake up from bed, first me and Daddy and Mommy, you, eat breakfast eat breakfast like we usually do, and then we're going to play and then soon as Daddy comes, Carl's going to come over, and then we're going to play a little while. And then Carl and Emily are both going down to the car with somebody, and we're going to ride to nursery school [whispered], and then when we get there, we're all going to get out of the car... */ int spam; /* Does this style look at all familiar? It should! */

En regardant ce fragment, vous ne savez peut-être pas si vous êtes dans la scope d’une méthode ou d’une classe.

L’utilisation de private ou de underscore dans le nom du champ ( private int spam; int spam_; ou int _spam; ) éliminera la confusion.

Dépend de vous. Faites ce qui est le mieux pour la lisibilité ou a du sens dans votre cas. Je les marque comme privés juste pour que ce soit clair.

Je pense que pour la lisibilité, il est toujours préférable d’être explicite.

De plus, vous pouvez consulter un plug-in de Visual Studio appelé Code Style Enforcer ( http://joel.fjorden.se/static.php?page=CodeStyleEnforcer ), qui utilise les extensions dxCore pour fournir des informations réelles. temps de réponse sur vos codes d’adhésion aux normes de codage (entièrement personnalisable).

Personnellement, je préfère marquer explicitement les champs privés et publics par défaut. Vous connaissez peut-être les valeurs par défaut, mais votre cerveau appréciera la verbosité chaque fois que vous scannez rapidement le code.