Ca doit faire un sacré sapin de noel à la fin, pas sûr que d'avoir autant de couleurs soit une bonne idée (au bout d'un moment, ça appelle la confusion entre couleurs, non?).
Personnellement, je préfère régler mon compilateur pour actionner le maximum de warning et les corriger, hors, le cas des shadow variables déclenche un warning. Je n'utilise également pas d'IDE, ce qui me permets d'éditer le code de n'importe quel logiciel sur mon PC en un temps record (tous les IDE que j'ai utilisés par le passé, probablement pas loin d'une dizaine, étaient lents à se lancer comparé à vim. Je n'ai jamais utilisé emacs, je ne sais donc pas pour cet OS, mais j'ai lu que son éditeur de code était pas génial).
Il y a aussi le cas des revues de code, notamment via l'outil de github, qui à ma connaissance ne supporte pas ce genre de fonctionnalité.
Bon, après, je suppose que c'est une question de goût.
Au passage, par curiosité je viens d'aller revoir rapidement la page de wikipedia sur cette notation. Du coup, je suis en désaccord avec tous ceux qui veulent sa suppression, parce que:
Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its intention or kind, and in some dialects its type. The original Hungarian notation uses intention or kind in its naming convention
Autrement dit, le but n'est pas seulement en rapport avec le type mais avec l'intention ou le type. Quant à la portée, elle est gérée initialement via la casse du 1er caractère non lié à la notation (given name comme ils disent).
Je note ici que l'article utilise le terme "kind" et non "type", ce qui est "expliqué" peu après:
As the Microsoft Windows division adopted the naming convention, they used the actual data type for naming, and this convention became widely spread through the Windows API; this is sometimes called Systems Hungarian notation.
En fait, ajouter le type (int, float, pointer, ...) dans le nommage n'est pas la notation hongroise, mais la notation hongroise système (je l'apprend, perso, comme quoi ça fait pas de mal d'aller fouiller parfois).
Exemples que j'ai trouvés pertinents dans la page wikipedia:
Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.
rwPosition : variable represents a row ("rw");
usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
Je ne doute pas qu'un outil d'analyse statique soit capable de détecter ce type d'information, mais je trouve personnellement la méthode de la notation hongroise bien plus simple et plus élégante que de faire des distinguo par couleur et autres. Et l'analyse statique, ça a un coût, tout le monde n'a pas une bête de course pour coder, notamment parce que ce n'est pas souvent si utile que ça (et pourtant je code en C++ hein), sauf pour des gros projets qui embarquent énormément de dépendances complexes dans chaque unité de compilation (utilisateurs de boost, je vous regarde).
Dans la liste des avantages défendus par ceux qui en sont adeptes, on retrouve d'ailleurs quelques-uns de ceux que j'ai cités: la lisibilité du code en dehors d'un IDE ("This is useful when looking at the code outside an integrated development environment — like on a code review or printout" j'avoue ne pas avoir osé parler d'imprimer le code, mais j'y avais bel et bien pensé, ça m'arrive de temps en temps d'utiliser le papier, même si c'est super rare), ainsi que le problème de la collision des noms ("Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision").
Au final, on pourrait dire qu'utiliser par exemple "mDistance" pour distance en mètres (ou mt pour meters, je sais pas. Le problème après c'est d'établir une convention quand ça à un intérêt de par l'usage assez répandu, sinon on ajoute juste des emmerdes), c'est de la notation hongroise, et il me semble avoir lu que c'est quelque chose qui manque souvent ;)
[^] # Re: Pas d'accord avec tout
Posté par freem . En réponse au lien [ANSSI] bonnes pratiques en C. Évalué à 3.
Ca doit faire un sacré sapin de noel à la fin, pas sûr que d'avoir autant de couleurs soit une bonne idée (au bout d'un moment, ça appelle la confusion entre couleurs, non?).
Personnellement, je préfère régler mon compilateur pour actionner le maximum de warning et les corriger, hors, le cas des shadow variables déclenche un warning. Je n'utilise également pas d'IDE, ce qui me permets d'éditer le code de n'importe quel logiciel sur mon PC en un temps record (tous les IDE que j'ai utilisés par le passé, probablement pas loin d'une dizaine, étaient lents à se lancer comparé à vim. Je n'ai jamais utilisé emacs, je ne sais donc pas pour cet OS, mais j'ai lu que son éditeur de code était pas génial).
Il y a aussi le cas des revues de code, notamment via l'outil de github, qui à ma connaissance ne supporte pas ce genre de fonctionnalité.
Bon, après, je suppose que c'est une question de goût.
Au passage, par curiosité je viens d'aller revoir rapidement la page de wikipedia sur cette notation. Du coup, je suis en désaccord avec tous ceux qui veulent sa suppression, parce que:
Autrement dit, le but n'est pas seulement en rapport avec le type mais avec l'intention ou le type. Quant à la portée, elle est gérée initialement via la casse du 1er caractère non lié à la notation (given name comme ils disent).
Je note ici que l'article utilise le terme "kind" et non "type", ce qui est "expliqué" peu après:
En fait, ajouter le type (int, float, pointer, ...) dans le nommage n'est pas la notation hongroise, mais la notation hongroise système (je l'apprend, perso, comme quoi ça fait pas de mal d'aller fouiller parfois).
Exemples que j'ai trouvés pertinents dans la page wikipedia:
Je ne doute pas qu'un outil d'analyse statique soit capable de détecter ce type d'information, mais je trouve personnellement la méthode de la notation hongroise bien plus simple et plus élégante que de faire des distinguo par couleur et autres. Et l'analyse statique, ça a un coût, tout le monde n'a pas une bête de course pour coder, notamment parce que ce n'est pas souvent si utile que ça (et pourtant je code en C++ hein), sauf pour des gros projets qui embarquent énormément de dépendances complexes dans chaque unité de compilation (utilisateurs de boost, je vous regarde).
Dans la liste des avantages défendus par ceux qui en sont adeptes, on retrouve d'ailleurs quelques-uns de ceux que j'ai cités: la lisibilité du code en dehors d'un IDE ("This is useful when looking at the code outside an integrated development environment — like on a code review or printout" j'avoue ne pas avoir osé parler d'imprimer le code, mais j'y avais bel et bien pensé, ça m'arrive de temps en temps d'utiliser le papier, même si c'est super rare), ainsi que le problème de la collision des noms ("Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision").
Au final, on pourrait dire qu'utiliser par exemple "mDistance" pour distance en mètres (ou mt pour meters, je sais pas. Le problème après c'est d'établir une convention quand ça à un intérêt de par l'usage assez répandu, sinon on ajoute juste des emmerdes), c'est de la notation hongroise, et il me semble avoir lu que c'est quelque chose qui manque souvent ;)