Nommez-vous les contrôles sur les formulaires en utilisant la même convention qu'une variable privée ?

Question

Pour une raison quelconque, je ne vois jamais cela se faire.Y a-t-il une raison pour laquelle pas ?Par exemple, j'aime _blah pour les variables privées, et au moins dans Windows Forms, les contrôles sont par défaut des variables membres privées, mais je ne me souviens pas les avoir jamais vues nommées de cette façon.Dans le cas où je crée/stocke des objets de contrôle dans des variables locales au sein d'une fonction membre, il est particulièrement utile d'avoir une certaine distinction visuelle.

Answer 1

Cela peut paraître contre-intuitif pour certains, mais nous utilisons la redoutable notation hongroise pour les éléments de l’interface utilisateur.

La logique est simple :pour tout objet de données donné, vous pouvez avoir deux contrôles ou plus qui lui sont associés.Par exemple, vous avez un contrôle qui indique une date de naissance sur une zone de texte, vous aurez :

• la zone de texte
• une étiquette indiquant que la zone de texte concerne les dates de naissance
• un contrôle de calendrier qui vous permettra de sélectionner une date

Pour cela, j'aurais lblBirthDate pour l'étiquette, txtBirthDate pour la zone de texte et calBirthDate pour le contrôle du calendrier.

Cependant, je suis intéressé de savoir comment les autres font cela.:)

Answer 2

Notation hongroise ou pas, je suis plus curieux de savoir si les gens ajoutent m_ ou _ ou tout ce qu'ils utilisent pour les variables privées standard.

Answer 3

Personnellement, je préfixe les objets privés avec _

Les contrôles de formulaire sont toujours préfixés par le type, le seulement la raison pour laquelle je fais cela est à cause d'Intellisense.Avec des formulaires volumineux, il devient plus facile « d'obtenir une valeur d'étiquette » en tapant simplement lbl et en le sélectionnant dans la liste ^_^ Il suit également le logique énoncée par Jon Limjap.

Bien que cela revienne aux directives de codage .NET de Microsoft, consultez-les ici.

Answer 4

Pour moi, la grande victoire de la convention de dénomination consistant à ajouter un trait de soulignement aux membres privés est liée à Intellisense.Étant donné que le trait de soulignement précède n'importe quelle lettre de l'alphabet, lorsque je fais un espace ctrl pour afficher Intellisense, il y a tous mes _privateMembers, juste en haut.

Les contrôles, cependant, sont une autre histoire, en ce qui concerne la dénomination.Je pense que cette portée est supposée, et ajouter quelques lettres au début pour indiquer le type (txtMyGroovyTextbox, par exemple) a plus de sens pour la même raison ;les contrôles sont regroupés dans Intellisense par type.

Mais au travail, c'est VB jusqu'au bout, et nous faisons mPrivateMember.Je pense que le m pourrait signifier module.

Answer 5

Je suis passé par VB et j'ai conservé le préfixe de type de contrôle pour les contrôles.Mes membres privés utilisent la casse camel inférieure (firstLetterLowercase) tandis que les membres publics utilisent la casse Pascal/majuscule camel (FirstLetterUppercase).

S'il y a trop d'identifiants/membres/locaux pour avoir 90 % de chances de se souvenir/deviner comment on l'appelle, plus d'abstraction est probablement nécessaire.

Je n'ai jamais été convaincu qu'un préfixe de type de stockage soit utile et/ou nécessaire.Cependant, j'ai pris l'habitude de suivre le style du code que j'utilise.

Answer 6

Non, mais j'apprécie votre logique.Je suppose que la raison pour laquelle la plupart des gens ne le font pas est que les traits de soulignement auraient l'air plutôt laids dans la fenêtre Propriétés au moment de la conception.Cela occuperait également un caractère supplémentaire d'espace horizontal, ce qui est primordial dans une fenêtre ancrée comme celle-là.

Answer 7

Notation hongroise ou non, je suis plus curieux de savoir si les gens ont constitué M_ ou _ ou tout ce qu'ils utilisent pour les variables de membres privés standard.

Luc,

J'utilise le préfixe _ pour mes objets de bibliothèque de classes.J'utilise la notation hongroise exclusivement pour l'interface utilisateur, pour la raison que j'ai indiquée.

Answer 8

Je n'utilise jamais de traits de soulignement dans les noms de mes variables.J'ai constaté que tout autre élément que les caractères alpha (parfois alphanumériques) est excessif, sauf si la langue l'exige.

Answer 9

Je suis dans le camp majuscules/minuscules ("titre" est privé, "titre" est public), mélangé à la notation "hongroise" pour les composants de l'interface utilisateur (tbTextbox, lblLabel etc.), et je suis heureux que nous n'ayons pas Développeurs Visual Case-Insensitive-Basic dans l'équipe :-)

Je n'aime pas le trait de soulignement parce qu'il a l'air un peu moche, mais je dois admettre qu'il a un avantage (ou un inconvénient, selon votre point de vue) :Dans le débogueur, toutes les variables privées seront au premier plan car le _ est au-dessus de l'alphabet.Mais là encore, je préfère que ma paire privée/publique soit ensemble, car cela permet un débogage plus facile de la logique getter/setter lorsque vous voyez les propriétés privée et publique l'une à côté de l'autre,

Answer 10

J'écris le nom de la colonne de base de données qu'ils représentent.

Answer 11

J'utilise m_ pour les variables membres, mais je suis de plus en plus tenté d'utiliser simplement lowerCamelCase comme je le fais pour les paramètres de méthode et les variables locales.Les éléments publics sont dans UpperCamelCase.

Cela semble être une convention plus ou moins acceptée au sein de la communauté .NET.