Préfixez-vous les noms de variable avec une abréviation des types de variable? (Notation hongroise) [fermé]

Dans mon travail actuel, il n'y a pas de directives de codage. Tout le monde code à peu près comme il veut. Ce qui est bien, car la société est petite.

Cependant, un nouveau gars a récemment proposé de toujours utiliser la notation hongroise. Jusqu'à présent, certains d'entre nous utilisaient une sorte de notation hongroise, d'autres non. Vous savez, c'est une société d'ingénierie, donc les styles de codage importent peu tant que les algorithmes sont sains.

Personnellement, j’ai le sentiment que ces abréviations sont un peu redondantes. Un nom bien pensé délivre généralement le même message. (En outre, la plupart de notre code doit fonctionner sur certains DSP bizarres, où un concept similaire boolou floatinexistant existe de toute façon).

Alors, que pensez-vous de la notation hongroise? L'utilisez vous? Pourquoi?

Quand la plupart des gens disent "Notation hongroise", ils parlent en fait de " Systèmes hongrois ".

Les systèmes hongrois sont complètement inutiles et doivent être évités. Il n'est pas nécessaire de coder le type de la variable dans son nom. Cependant, Systems Hungarian est en réalité un malentendu du premier "vrai" hongrois: Apps Hungarian.

Dans Apps Hungarian, vous n'encodez pas le "type" dans le nom de la variable, vous encodez le "type" de la variable. Donc non nWidth, mais pxWidthou emWidth(pour "largeur en pixels" ou "largeur en ems" respectivement). Not strNamebut sNameor ou usName(pour "nom de sécurité" ou "nom de sécurité" - utile pour accepter une entrée d'utilisateurs: chaînes non protégées).

Personnellement, je ne m'occupe généralement pas non plus. À moins que je ne fasse quelque chose qui convertisse explicitement le "type" d'une valeur (par exemple, j'ai déjà utilisé les préfixes "px" et "em" parce que les erreurs sont pxArea = emWidth * emHeightévidentes).

Voir également l'article de Joel intitulé " Making Wrong Code Wrong Wrong ".

pronomVotre verbeIl ne faut jamais verbeUtiliser un adjectifNom hongroisNotation, prépositionIl verbeMakes collectivenounTout adverbeSou comparatifBloody adjectifHard infinitifTo verbeLire.

D'abord:

Vous savez, c'est une société d'ingénierie, donc les styles de codage importent peu tant que les algorithmes sont sains.

Les styles de codage importent peu importe la société. Oui, les algorithmes doivent être sains, mais le code doit être maintenable par tout le monde, pas seulement par le développeur d'origine. Avoir une norme de codage qui inclut des éléments de style est un moyen d'y parvenir. Je ne dis pas que tout le code devrait être identique dans son style - ce serait contre-productif, mais il devrait y avoir un certain degré de cohérence.

Passons maintenant à la notation hongroise:

Bien qu’elle ait eu ses utilisations, avec un IDE moderne prenant en charge les comportements de type IntelliSense, il n’est pas nécessaire d’inclure le type de la variable dans son nom. Cette information est disponible pour vous d'une autre manière. Au pire, cela peut rendre le code plus difficile à lire si vous devez changer le type de la variable à l'avenir.

Ne l'utilisez pas. Il est redondant et rend le code plus difficile à lire.

Une grande partie du débat sur la notation hongroise (système) dépend du domaine d’activité. J'avais l'habitude d'être très fermement du côté "aucun moyen!", Mais après avoir travaillé pendant quelques années dans une entreprise où il est utilisé pour le développement intégré, je peux voir certains avantages de celui-ci dans certaines applications et cela m'a définitivement poussé. .

Systèmes Hongrois

D'après ce que je peux dire, Systems Hungarian a tendance à être beaucoup utilisé dans le domaine des systèmes embarqués. Dans les applications PC, le compilateur résoudra de nombreux problèmes liés aux différences entre, par exemple, les chaînes, les entiers et les valeurs en virgule flottante. Sur une plate-forme profondément intégrée, vous vous inquiétez plus souvent des différences entre les entiers non signés 8 bits, les entiers signés 16 bits, etc. Le compilateur (ou même une charpente avec règles MISRA appliquées) ne les détecte pas toujours. Dans ce cas, avoir des noms de variables comme u8ReadIndex, s16ADCValuepeut être utile.

Apps Hongrois

Apps Hungarian présente des avantages certains en ce qui concerne les applications PC / Web, par exemple en offrant une différence visuelle entre les chaînes "non sécurisées" et les chaînes "sûres" (c'est-à-dire celles entrées par un utilisateur et celles qui ont été échappées ou lues à partir de ressources internes ou autre). ). Le compilateur n'a aucune connaissance de cette distinction.

À quoi ça sert?

Utilisation de (systèmes ou applications) Le hongrois consiste à donner l’ impression d’un code erroné .

Si vous copiez une chaîne non sécurisée directement dans une chaîne sécurisée sans en échapper, le résultat sera faux si vous utilisez Apps Hungarian.

Si vous multipliez un entier signé par un entier non signé, le compilateur promouvra (souvent silencieusement) celui-ci en un (potentiellement énorme) non signé, ce qui pourrait entraîner une erreur: Systems Hungarian donne une apparence erronée.

Dans ces deux cas, la notation hongroise (applications / systèmes) tend à rendre les révisions de code formelles plus rapides car il est moins fait référence au type de la variable.

Global

Dans l’ensemble, j’estime que le plus important est d’avoir une norme de codage. Qu'il s'agisse d'utiliser Systems Hungarian, Apps Hungarian ou aucun des deux n'est une question de préférence personnelle ou de groupe, un peu comme le choix du type d'indentation, etc. Cependant, l'équipe de développement dans son ensemble a des avantages certains à travailler avec la même préférence.

La notation hongroise a pour objet de coder dans l'identificateur des informations qui ne pourraient autrement pas être codées dans le système de types. Mon opinion personnelle est que si cette information est suffisamment importante pour être encodée, elle l'est suffisamment pour être encodée dans le système de types, où elle peut être vérifiée correctement. Et si l’information n’a pas d’importance, pourquoi alors vous voulez encombrer votre code source?

Ou, pour le dire plus succinctement: les informations de type appartiennent au système de types. (Note: il n'a pas besoin d'être un statique système de type Tant qu'il attrape les erreurs de type, je ne se soucient pas. Quand il les attrape.)

Quelques autres réponses ont mentionné les unités de mesure comme utilisations acceptables de la notation hongroise. (Je suis un peu surpris que personne n'ait encore mentionné Mars Orbiter de la NASA, car cela semble être une question récurrente dans les discussions sur la notation hongroise).

Voici un exemple simple en F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Ecoute, maman, pas de Hongrois!

Si je devais utiliser la notation hongroise au lieu de types ici, cela ne me aider un peu:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Le compilateur l'a laissé passer. Je compte maintenant sur un humain pour repérer ce qui est essentiellement une erreur de type. N'est-ce pas ce à quoi sert un vérificateur de types?

Encore mieux, en utilisant le langage de programmation Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Donc, en résumé: je n'aime pas la notation hongroise. Vous ne devriez jamais l'utiliser.

Cela dit, je pense que l’utilisation de la notation hongroise est une bonne idée. Attends quoi?

Oui! Dans ce cas particulier , vous avez mentionné:

De plus, la plupart de notre code doit fonctionner sur certains DSP bizarres, où un concept comme bool ou float n'existe de toute façon pas.

Mais c’est précisément le seul cas d’utilisation judicieux de la notation hongroise!

PS: Je recommande vivement de regarder Frink. Son manuel contient quelques-unes des blagues les plus impressionnantes de tous les temps. C'est aussi une langue plutôt cool :-)

Cela n'a pas de sens dans un langage orienté objet - tout est un type qui apparaît lorsque vous essayez de l'utiliser.

Le seul endroit où Systems Hungarian est garanti est avec un langage faiblement typé tel que C. C'est d'autant plus important avec C qu'il n'y a pas d'objet explicite (il a des structures, mais toutes les fonctions sont externes à la structure). Dans quelque chose de plus fortement typé comme C ++, Java et C #, cela n'aide en rien et aggrave les choses. Le code change, et il est beaucoup plus facile de changer un type que de changer tous les espaces où vous utilisez un nom de variable. C'est aussi un travail inutile inutile qui a tendance à être ignoré.

Si vous avez des unités de mesure, il peut être utile de coder cela dans un nom - mais au final, cela peut aussi être du bruit supplémentaire. Par exemple, nous allons déclarer l'unité de mesure standard pour les différentes choses avec lesquelles nous travaillons dans notre code. Par exemple, utilisons-nous des gradients ou des degrés, des mètres ou des pieds, des cadres ou des millisecondes? Une fois la norme définie pour le code, chaque fois que nous lisons dans une unité de mesure, nous convertissons toujours immédiatement en unité de mesure standard pour le code.

Mon conseil : commencez par les points douloureux actuels et choisissez un standard raisonnable pour cette partie du code. Sur-spécifier une norme de codage est contre-productif. Il est très utile d’avoir des noms de variables et de champs qui expliquent ce qu’ils représentent, et la plupart du temps, vous pouvez en déduire le type à partir du concept.

HECK NO!

Ne pas utiliser la notation hongroise ou toute autre notation. En tant que programmeurs, nous ne devrions pas utiliser "notation" pour nos noms de variables.

Ce que nous devrions faire, c’est bien nommer nos variables :

• Évitez les noms trop généraux. Ne le nommez pas zs'il s'agit d'une variable de classe représentant un objet nommé, par exemple une facture téléphonique. Appelez ça phoneBillou PhoneBill.

• Évitez les noms trop spécifiques. Lorsque quelque chose est clair sans information supplémentaire, ne l'incluez pas. S'il ne s'agit que d'une variable d'index de chaîne permettant de parcourir en boucle les caractères d'une chaîne et que vous ne l'utilisez qu'une fois dans la fonction MyFunc, pourquoi l'appelleriez-vous jamais MyFuncTempStringCharacterIndex? C'est une blague triste. Appelez-le Posou même isi vous aimez. En contexte, le prochain programmeur comprendra facilement ce que cela signifie.

• Lorsque vous déterminez si un nom doit être général ou spécifique, considérez le domaine dans lequel il se trouve et le contexte des autres significations possibles. Dans le cas étroit où il y a deux éléments de type similaire faciles à confondre et utilisés de la même manière, il est alors bon de trouver un préfixe ou un suffixe pour indiquer cette différence. Gardez-le aussi court que possible.

Comme d'autres intervenants l'ont dit, c'est ce cas étroit qui a lancé "Apps Hungarian" pour distinguer les mesures relatives à la fenêtre de celles rwTabPositionrelatives au document rdTabPosition. Mais dans une application qui fait tout ce qui est relatif au document, n'ajoutez rien de plus cruel! En fait, pourquoi ne pas utiliser l’idée de Jörg W Mittag de créer un nouveau type à partir de celui-ci? Ensuite, vous ne pouvez pas éventuellement mélanger les choses.

Dans presque tous les domaines, l'ajout d'éléments ayant une densité de signification minimale réduit la signification globale et la facilité de compréhension. Voici un exemple de Ben Franklin . Et un autre exemple: il est possible en anglais de décorer nos mots avec leur partie du discours. C'est plus d'informations, n'est-ce pas? Au cas où les débutants en anglais seraient confus, cela pourrait leur être très utile, non? Lisez ceci et dites-moi à quel point vous pensez que cela est utile pour la compréhension à long terme et la communication efficace de l'information:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. Préparez vos programmes, prévenez-les plutôt que vous ne les appelez pas "nomenclature", par exemple.

En ajoutant des informations, je faisais cela une douleur complète à lire.

Alors oublie la notation. Oubliez les préfixes spéciaux que vous ajoutez toujours. À mon avis, la seule vraie directive ici devrait être:

Gardez les noms de variable aussi courts que possible, aussi significatifs que nécessaire et toujours sans ambiguïté .

Le but d'un identifiant est plus important que son type. Si vous utilisez des noms descriptifs pour les identificateurs dans vos programmes, vous n'avez pas besoin d'utiliser des notations hongroises. isConnectedest toujours plus lisible et facile à comprendre que boolConnected.

Nous utilisions le hongrois à l'époque où j'étais programmeur C ++ et c'était génial. Vous pourriez voir le type d'une variable (par exemple, BSTR, CString, LPCTSTR ou char *) sans rechercher la déclaration. À cette époque, vous recherchiez la déclaration en faisant:

1. ctrl-home
2. ctrl-F
3. Nom de variable
4. entrer

Donc, cela importait un peu. Mais quelque part autour de 2000, quelques événements se sont produits:

• les éditeurs sont devenus assez intelligents pour afficher le type de variable sous forme d'infobulle
• les éditeurs disposaient d'un raccourci "aller à la déclaration" et d'un moyen rapide de revenir en arrière
• C ++ a été moins utilisé et la plupart des autres langages ont moins de types de variables. Par exemple, en C #, vous êtes presque certain que lastNamec'est un System.String, car il n'y a qu'une seule classe de chaîne.

J'ai été l'un des derniers à abandonner le hongrois et maintenant, quand je lis l'ancien code source, cela m'agace.

Je déteste juste la notation hongroise, je préfère utiliser des traits de soulignement pour délimiter les noms de variables.

De plus, lorsque vous mettez le type comme première lettre au début du nom de votre variable, procédez comme suit: float fvelocity; vect vDirection; chaîne ** ppszWord;

l'auto-complétion les trie toutes et vous avez du mal à trouver ce que vous voulez, et les gens ont tendance à utiliser ce qu'ils pensent être mieux, et ce n'est plus une notation.

J'aime juste écrire ThingsLikeThat lorsque j'ai besoin d'être très descriptif à propos de la variable, car elle économise de l'espace et le fait qu'il y ait des majuscules la rend plus lisible.

Ce que je fais habituellement, c’est nommer mes méthodes et mes classes avec la première lettre en majuscule, et en minuscule pour les noms de variable, et un trait de soulignement pour les noms de variable (je trouve ce dernier utile).

Sérieusement, je préfère que les gens se soucient de ces règles: Utilisez des virgules, des arithmétiques et des accolades avec des espaces appropriés:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Pas plus de 80 caractères par ligne, ou AU PLUS 90 caractères, utilisez des arguments multi-lignes pour les fonctions ou long if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

D'accord avec la plupart, c'est un style ancien.

Avec les IDE modernes, un survol rapide d’une variable montre le type.