2010-10-25 21 views
4

Je suis entièrement d'accord que nous ne devrions pas utiliser la notation hongroise pour nommer les variables. Mais il semble que la notation hongroise soit toujours utile pour nommer les contrôles (en particulier les contrôles Winform). Tenez compte de ces:Utilisez-vous la notation hongroise pour les noms de contrôle?

GridView grvUsers 
TextBox txtPassword 

etc ...

Je doute vraiment que devrions-nous éviter la notation hongroise dans ce cas? Si c'est le cas, quelle est la solution alternative pour nommer les contrôles?

+0

Utilisez-vous des noms bibliques pour les enfants? C'est essentiellement la même question. –

+0

@ vimvq1987: Désolé, je ne suis pas en mesure de vous aider ... :(:( –

Répondre

1

Je nomme généralement les contrôles en fonction de ce qu'ils sont, mais avec plus de noms anglais. Comme, je vais nommer un contrôle d'étiquette pour une boîte de prénom, "FirstNameLabel", et la zone de texte "FirstNameBox". Ce n'était même pas intentionnel; J'ai juste remarqué un jour que je le faisais, et il était logique de continuer à le faire. Je pense que je vais appeler ça "notation américaine".

+0

Même ici, mais en minuscule premier caractère car ce sont des champs privés –

5

Qu'elle soit bonne ou mauvaise, c'est toujours la norme de facto d'utiliser la notation hongroise pour les contrôles de dénomination, et il semble très hors de propos de ne pas l'adopter. De la même manière que les méthodes dans les langages .NET utilisent Pascal Casing (alors que dans la plupart des autres langages il est désapprouvé), sortir des conventions acceptées pour l'environnement dans lequel vous travaillez a tendance à rendre votre code encore plus ... d'endroit. Je suis personnellement en faveur de la pratique, car elle permet de distinguer les membres de classe qui font partie de l'interface utilisateur (vue) des membres qui font partie du code-behind (modèle/contrôleur). Si les variables de contrôle reçoivent des noms similaires à ceux utilisés pour stocker les données, l'état, etc., alors j'ai l'impression qu'il est plus difficile de résister à la tentation de coupler étroitement les deux. Bien sûr, une séparation plus nette de la logique permettrait de surmonter cela aussi bien.

Néanmoins, la notation hongroise ne laisse aucun doute quant aux variables qui font partie de l'interface utilisateur, et précise également leur type et leur fonction, tant dans le concepteur que dans l'éditeur de code.

+3

Peu importe que MS a dit "ne le fais pas". Peu importe que tous les EDI utiles existant maintenant puissent vous dire le type d'une variable simplement en passant la souris sur son nom.Même si vous ne pouvez pas lire les noms à haute voix sans être gênant. décrivez le * type * de choses, pas la classe, cela ne vous dérange pas que si vous changez cette zone de texte en un éditeur de texte enrichi plus tard, * vos noms de variables vous mentent * Non, cette pratique * doit * mourir * – cHao

+0

cHao: Comment devrait-on nommer un contrôle pour le distinguer de la propriété qui lui est associée? – supercat

+0

@supercat: Si vous séparez vos préoccupations décemment, alors il n'y aura pas une telle propriété Votre forme n'est pas les données, c'est un * vue * des données Idée Si le formulaire a un objet modèle représentant les données affichées/manipulées, les gestionnaires d'événements des contrôles modifieront les propriétés de cet objet. – cHao