Luttant pour ne pas utiliser la notation hongroise


10

J'ai vu des arguments pour et contre Systems Hungarian . Depuis quelques années, je travaille sur un projet hérité qui utilise ce système en nommant chaque variable, fonction avec un préfixe du type de variable, par exemple (strName, intAge, btnSubmit etc.) (je connais les préfixes hongrois d'origine des applications par le type de variable, pas le type). J'aimerais que mon prochain projet l'abandonne complètement, mais j'ai du mal à nommer des choses similaires sans y avoir recours.

Disons que j'ai un formulaire Web pour collecter les adresses e-mail et les stocker dans une table de base de données, et un bouton qui appelle la fonction qui enregistre l'adresse dans la base de données.

Si j'utilise la notation de style hongrois, je pourrais appeler la case txtEmaille bouton btnEmailet la valeur contenue dans la zone de texte strEmail. Je pourrais alors utiliser une fonction storeEmail(strEmail)pour stocker l'e-mail. J'ai une convention claire ici, il est évident quelle est chaque variable.

Quelle serait la meilleure pratique pour nommer ces variables

  • sans avoir recours aux systèmes hongrois,
  • sans les rendre trop longs ou déroutants
  • et avec une convention claire à utiliser sur l'ensemble de mon projet?

2
Peut-être y a-t-il un problème avec le reste de vos conventions de dénomination ou la taille de vos fonctions si vous avez du mal à trouver des noms uniques.

Quelle technologie utilisez-vous? Ces préfixes semblent se prêter aux formulaires Web.
StuperUser

J'utilise ASP.NET (avec C # derrière)
fearoffours

@delnan - pouvez-vous élaborer s'il vous plaît? Pourquoi la taille des fonctions facilite-t-elle la dénomination?
fearoffours

@fearofours: Une fonction plus petite a besoin de moins de variables, et moins de variables signifient évidemment moins de conflits de variables. Cela suppose bien sûr que vous placiez chaque variable dans la plus petite portée possible.

Réponses:


8

Votre dernier point est le plus important - quoi que vous fassiez, vous devez être cohérent dans votre projet et avec vos collègues. Il y a deux manières principales de réaliser la cohérence et si possible vous devriez utiliser les deux. Utilisez d'abord un outil pour vérifier les conventions de dénomination au moment de la construction. Dans le monde .Net, StyleCop serait un bon exemple d'un tel outil. La deuxième façon d'obtenir de la cohérence est d'avoir des revues par les pairs de tout le code, afin que vous puissiez tous garder un œil.

Vos deux autres points semblent demander une alternative. Je ne suis pas sûr que vous ayez besoin d'une alternative; le point sur le hongrois qui n'est plus populaire est qu'il était utilisé pour décrire le type lorsque le système de type et les outils étaient un peu, disons, moins stricts. C'est-à-dire si vous programmiez en C et passiez des pointeurs autour de la seule façon de garder une trace du type était d'utiliser le hongrois. Maintenant, si vous utilisez un langage comme C # ou Java, vous n'utiliserez pas de pointeurs (ou très rarement), donc le besoin de tout type de hongrois disparaît. De plus, les IDE modernes vous permettent de voir le type très facilement en survolant la variable ou au pire en utilisant un raccourci pour voir la déclaration d'origine. Donc, je ne pense pas que vous ayez besoin d'une sorte de notation, il suffit de nommer la variable par ce qu'elle fait. S'il s'agit d'une adresse e-mail, utilisez simplement "e-mail" ou "


2
Cela devient un peu plus compliqué lorsque le formulaire / page / fenêtre / tout ce qui a un bouton pour le courrier électronique, une zone de texte pour le courrier électronique, et peut-être un autre widget / contrôle pour le courrier électronique ...
FrustratedWithFormsDesigner

7
@FrustratedWithFormsDesigner Pas nécessairement. La zone de texte peut être emailAddressInput alors que le bouton est emailAddressSubmit et la représentation interne être simplement emailAddress.
Jonathan

@Jonathan: Bon point.
FrustratedWithFormsDesigner

3

Lorsque vous traitez des formulaires Web / Windows ou d'autres éléments graphiques, il est judicieux d'utiliser les systèmes hongrois car vous pouvez avoir des contrôles qui sont très étroitement liés, par exemple, une zone de texte et une étiquette qui vont ensemble; vous pourriez les nommer txtEmailet lblEmailles distinguer. D'après mon expérience, cela est courant et est en fait utile.

Mais dans votre code-behind, ce type de dénomination n'est pas nécessaire. Si vous avez une variable de type stringutilisée pour stocker un e-mail, nommez-la simplement email. Si, pour une raison quelconque, vous vous trompez, la plupart des IDE devraient vous permettre de survoler et de voir son type. (Idéalement, dans les trucs OO, cela pourrait être un attribut d'un objet, et user.Emailc'est encore plus clair.)

Je pense que si vous avez plus d'un objet déclaré dans votre code qui n'est pas un contrôle GUI qui pourrait être correctement nommé email, quelque chose est intrinsèquement incorrect avec votre conception.


1
En réalité, txt et lbl ne sont pas hongrois, txt est simplement abrégé pour Text et lbl est abrégé pour Label, il n'y a aucune raison de ne pas simplement utiliser le mot entier, par exemple EmailText et EmailLabel sur un formulaire. Le hongrois serait le type, qui dans les deux cas est une chaîne.
Steve

1
@Steve Haigh - Non, je parle des commandes elles-mêmes. Vous avez un objet de type "zone de texte" appelé txtEmail, et un objet de type "label" appelé lblEmail. Ni l'un ni l'autre ne sont des cordes. Ils peuvent avoir des propriétés de chaîne, mais ils ne sont pas eux-mêmes des chaînes.
Andrew Arnold

1
Ah désolé. Oui bien sûr. Même ainsi, il n'y a aucune raison de ne pas utiliser un nom plus descriptif tel que EmailTextBox. Ce n'est pas parce que VS génère un mauvais nom que vous devez le garder. Cependant, dans le contexte des formulaires, les abréviations txt et lbl sont si bien comprises que je ne m'inquiéterais probablement pas dans ce cas.
Steve

3

Qu'est-ce qui rend une variable "trop ​​longue"?

Au lieu de txtEmail, btnEmailvous pouvez utiliser UserEmailText, UserEmailButtonet AdminEmailText,AdminEmailButton

Le problème avec cela est que vous pourriez commencer à sentir que la variable commence à devenir longue:

AdminEmailIsValid commence à délimiter la durée pendant laquelle j'autoriserais la variable.

En outre, vous pouvez commencer à remarquer que vous réutilisez un ensemble de variables et un ensemble d'opérations sur ces variables. C'est pour cela que la POO est conçue . Au lieu d'un ensemble de variables, créez un objet générique:

class EmailForm
  var textBox, button, text
  function storeEmail()

Ensuite, vous pouvez instancier une nouvelle variable en tant que classe et utiliser la même notation par points pour accéder à vos données:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Bien sûr, cela cible les langages qui utilisent le paradigme OOP, mais la majorité des langages de développement Web populaires sont orientés objet ou autorisent le code orienté objet (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, etc. ).


Je ne vois pas l'avantage de UserEmailText sur txtEmail - vous suffixez simplement le type plutôt que de le préfixer. J'aime bien "C'est pour cela que la POO est conçue".
fearoffours

@fearoffours, OP a admis avoir un problème avec des noms uniques, j'ai ajouté cet exemple comme moyen descriptif de distinguer entre deux variables similaires ( UserEmailTextet AdminEmailTextspécifiquement). J'ai généralement des types de suffixe car il se prête à passer à une classe UserEmailText-> UserEmail.text-> User.email.textselon la quantité d'abstraction / fonctionnalité nécessaire.
zzzzBov

OK, voyez d'où vous venez. +1 pour la comparaison suffixe / classe. Oh, et je suis l'OP!
fearoffours

@fearoffours, lol whoops ...
zzzzBov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.