Le MFC a tous les noms de classe commençant par C. Par exemple, CFILE et CGDIOBJECT. Quelqu'un a-t-il vu qu'il a utilisé ailleurs? Existe-t-il un guide officiel de la convention de nommage de Microsoft qui recommande ce style? L'idée est-elle originaire de MFC ou était-ce un autre projet?
12 Réponses :
Nous l'utilisons au travail, comme beaucoup d'autres conventions de nommage
Par beaucoup, je voulais dire c pour les classes, P pour le pointeur, m_ pour les membres, S_ pour les membres statiques, n pour entier ... pas beaucoup de documents
Je ne peux pas répondre à toutes vos questions, mais aussi loin que je sache, il s'agit simplement de distinguer les classes MFC d'autres classes - une forme de notation hongroise.
Fait intéressant, il est apparemment controversé non seulement à l'extérieur de la SM, mais à l'intérieur aussi bien .
Ouais bien, que savent-ils - les directives .NET (par exemple) rejeter l'idée de classes de préfixe, mais conviennent parfaitement aux interfaces de préfixe. Parfois, la controverse est là pour aucune bonne raison.
C'était un ancien style de codage C ++ et MFC était probablement l'une des dernières choses à l'utiliser.
Ce n'était généralement qu'une convention de C ++ (et peut-être quelques autres langues), et il a donc commencé à tomber hors service car les langues sont devenues plus interopérables, via Com, puis .net.
Vous voyez toujours que c'est cousin, le préfixe "I" pour les interfaces, assez souvent. J'ai toujours trouvé intéressant que "i" a survécu lorsque "C" est mort, mais c'était probablement parce que les interfaces ont été utilisées si fortement dans l'interopérabilité de com.
Je pense qu'il est important de communiquer clairement le fait qu'une classe est censée être une interface et une préfixation avec i pourrait toujours être largement utilisée car elle est plus courte et plus claire, alors dites un base suffixe.
Cela ne meurt probablement pas car il aborde les minorités (interface, paramètres de type générique) et les classes les plus courantes ne reçoivent pas de fouillis.
Alors qui d'autre l'a utilisé? Seulement Microsoft?
Il est souvent utilisé dans le code tiers à l'aide de MFC / ATL / WTL. Au fait, je crois que la dernière chose qui a utilisé cette convention était en réalité wtl. Beaucoup de code MS utilise aussi bien - par exemple. Regardez le rotor.
@ User1 - Le hibou de Borland a utilisé T (pour le type, je crois) au préfixe des noms de classe
Non, ce n'était jamais commun dans la terre C ++ aussi loin que possible, Microsoft a été le premier à préfixer avec C pour se distinguer de Apple / Borland, qui a utilisé T. Après les premières versions de MFC, les programmeurs ont commencé à préfixer leurs propres cours avec C, donc ms a commencé la chose plutôt que de la mettre fin. Je ne me souviens pas d'avoir vu un livre C ++ qui a utilisé des préfixes C, pas même les livres «anciens» C ++ (milieu des années 80 à 1990). Voir Jelovic.com/articles/stupid_naming.htm .
@Roel, ma déclaration était basée sur le fait que je l'ai vue utilisé dans les programmes Turbo C ++ à la mi-90, bien avant que je n'ai jamais vu et la version Microsoft de C ++. En outre, c'était la convention de dénomination qu'ils enseignaient à mon collège à la fin des années 90, ce qui n'utilisait à nouveau aucune chose de MS C ++. Mais bien sûr, il peut avoir commencé avec la SP et filtré à ces autres envissions
Le préfixe i a survécu principalement pour deux raisons, une pragmatique et une technique. Le pragmatique étant, que lorsque vous implémentez un objet COM dans C ++, vous dérivez généralement de l'interface que vous implémentez. Vous devez nommer à la fois le type de l'objet ainsi que l'interface, et bien qu'ils soient souvent identiques, le préfixe i empêche un nom de nom. Sur le côté technique, les types d'interface (en particulier avec COM) apparaissent dans des signatures de méthode. Une fois publié, vous ne pouvez plus changer ceux-ci. Nous allons voir le préfixe i pour tant que COM et / ou le temps d'exécution Windows survivre.
C'est mal. N'utilisez pas la notation hongroise pour autre chose que des choses abstraites.
Par exemple, Mais des choses comme btnsubmit est correct pour décrire un bouton nommé Soumettre (qui aurait un lblsubmit pour l'étiquette à côté du bouton)
cmyclass pour la classe et uicount pour INTEGER inte non signé Named Count n'aider pas les programmeurs et conduit à une dactylographie supplémentaire.
@ARLZ: Je ne suis pas d'accord avec votre déclaration à propos de UICOUNT et de dactylographie supplémentaire. Si je lis quelque chose comme "Si (Uixcoord <0)" Un voyant rouge commence à clignoter, mais pas si je lisais "si (XCOORD <0)" et XCOORD est un INTR. Et en tapant des caractères supplémentaires ne seront jamais une raison pour laquelle un logiciel n'est pas prêt à temps, le code de frappe est le plus petit problème qu'un développeur de logiciels a. Savoir quoi tapir est beaucoup plus important.
@HABI: Dans de telles situations, vous préférez plutôt vouloir écouter les avertissements du compilateur. En outre, utilisez peut-être plus de noms variables descriptifs - quelle est la raison pour laquelle une coordonnée X générique doit être non signée?
@HABI: Que se passe-t-il lorsque le type change pour uicount à partir d'un non signé int sur non signé long , signé int ou double ? Selon la notation hongroise, la variable doit être renommée, partout il est utilisé. Selon la validation, toute fonction ou méthode modifiée doit être testée. Ressemble au début des tests de régression complètes. :-(
@Unclebens: Mon opinion est que la notation hongroise (HN) est utile si elle est utilisée avec précision. L'écoute des avertissements du compilateur n'aide pas pendant les revues de code et les analyses pré-codent. En particulier, les compilateurs pour systèmes embarqués sont plutôt faibles à ce moment-là. Je connais au moins un compilateur qui ne ferait pas avertir dans ce cas même au plus haut niveau d'avertissement. Eh bien, vous avez raison, l'exemple donné n'est pas le meilleur. Néanmoins, j'aime bien voir le type d'une variable à la volée juste en lisant le code. Et le typing supplémentaire est l'argument le plus faible contre Hn.
Pendant que je suis d'accord, Eschetez la notation Hungerian. Je vois le C ou I préfixe comme plus un mécanisme de désambiguïssement pour éviter une classe et son interface ayant le même nom (pas si mal). H.n., d'autre part, est une tentative laide / redondante / problématique de faire des informations de type (de variables) plus visibles. Personnellement, je saisis simplement les noms de classe et seulement préfixe avec I s'il s'agit d'une interface COM.
@Thomas m.: Vous avez raison, vous devez tester le code où la variable est utilisée. Mais vous devez le faire quand même, avec ou sans HN (notation hongroise). Puisque vous devez changer la nommée partout, vous savez ce que vous devez tester. C'est l'un des principaux avantages de la HN et la principale raison pour laquelle nous l'utilisons. Nous développons des dispositifs médicaux. Changer le type d'une variable sans vérifier qui influence cela n'a vraiment aucune bonne idée, pas seulement pour les dispositifs médicaux. HN vous oblige au moins à regarder où une variable est utilisée si vous modifiez le type.
@HABI, n'est-ce pas «vérifier que tout fonctionne» "quelque chose à faire dans [automatisé] tests d'unité / de régression?
@ARLZ: Si le type d'une variable est modifié, il est nécessaire de vérifier quelles influences cela a et si les tests existants sont toujours appropriés / suffisants. Peut-être que vous devez adapter les tests aussi.
Le bon type de notation hongroise peut avoir des utilisations vaguement utiles, telles que la vérification de bricolage. Par exemple, vous pouvez délimiter une frontière entre «Safe» (signification assainissée et / ou échappée, généralement) des chaînes et «dangereuses» à l'aide d'applications Hongrois: Uname est un nom non coché de la saisie de l'utilisateur, < Code> Sname est un nom de sécurité, ugetname renvoie une chaîne non cochée, sgetname retourne un coffre-fort. Char * Sescape (Char * Uname) blanchisseurs une chaîne. La partie pratique est votre partie jamais passez une variable nommée u à une fonction avec un paramètre nommé s . Ne vaut pas toujours l'effort, bien sûr.
Je ne comprends pas le besoin du préfixe Types de préfixes HN - En général, j'ai déjà fait une grosse erreur si j'en aurais besoin parce que j'ai alors écrit mon code de manière à déclencher des avertissements ou des erreurs de compilation. Je reconnais que je fais des erreurs mineures à plusieurs reprises et j'essaie d'écrire d'une manière afin que je puisse les attraper à la compilée.
Il n'est absolument pas le mal : c'est juste une convention de dénomination à l'ancienne maintenant plus largement remplacée par des idées puissants
@geo: apps La notation hongroise est sans aucun doute utile. Il permet aux auteurs du code de transmettre des informations sémantiques, qui ne peuvent (facilement) être transmis autrement. Comme un int qui pourrait représenter des pixels dans des unités logiques ou de périphériques, ou la taille d'un tampon en octets ou caractères, etc. Il est difficile, même avec les compilateurs d'aujourd'hui, de concevoir des types personnalisés pour chacun de ceux-ci et fournir des conversions (sensées) nécessite des efforts exponentiels. En 40 ans, C ++ a réussi à introduire un type d'unité Single (heure). Cela dit beaucoup.
Quelque chose d'un peu similaire est utilisé en Symbian C ++, où la Convention est celle:
t Classes sont des "valeurs", par exemple TCHAR, TINT32, TDES
r classes sont des poignées aux ressources du noyau (ou d'autres), par exemple RFILE, RSOCKET Les classes
M sont des mixes, qui comprend des interfaces (interprétées comme des mixes sans implémentations de fonction). La ligne directrice est que plusieurs héritages devraient impliquer au plus 1 classe non M.
Casses C sont à peu près tout le reste et dérivent de CBASE, qui a des éléments debout pour aider à la manipulation des ressources.
HBUFC existe principalement pour générer des poteaux confus sur des forums Symbian et avoir son propre préfixe n'est que le début. Le H signifie "hein?", Ou éventuellement "Haw, Haw! Tu n'as pas de stl!" ; -)
Ceci est proche de l'Esprit pour applications à la notation hongroise plutôt que de la notation hongroise des systèmes. Le préfixe vous dit quelque chose à propos de la classe que vous pourriez rechercher dans la documentation, mais que vous ne sauriez pas autrement. L'ensemble du point de nommer quoi que ce soit dans la programmation consiste à fournir de telles astuces et rappels , sinon vous venez d'appeler vos classes "Class001", "Class002", etc.
Systems Hongrois vous indique simplement le type d'une variable, que l'OMI n'est rien pour devenir très excitée, en particulier dans une langue comme C ++, où les types ont tendance à être répétés constamment ou complètement cachés par des paramètres de modèle. Son analogue lorsque les types de nommage sont la pratique Java de nommer toutes les interfaces avec I. Encore une fois, je ne suis pas très excitée à ce sujet (et non les bibliothèques Java standard), mais si vous allez définir une interface pour chaque classe , En plus des interfaces qui sont réellement utilisées pour le polymorphisme dans des situations non testées, vous avez besoin d'un moyen de distinguer les deux.
Il y a des années, la convention de nommage est cruciale pour aider à identifier la classe, même au groupement de la classe. N'oubliez pas, puis il n'y avait pas d'espace de noms et non / Intellisense disponible. C est une forme de notation hongroise mais certainement rendue populaire par MFC. Borland et Delphi utilisaient T - comme préfixe pour type
Un autre choix de conception MFC basé sur ce que le compilateur MS a soutenu il y a vingt ans plutôt que de la manière dont il serait fait dans le C ++ moderne.
Je me souviens des compilateurs de Borland venus avec des bibliothèques où les noms de classe ont commencé avec 'T'. Probablement pour "type" :)
J'ai toujours cru que c'était à cause du T dans Turbo Pascal / Turbo C ... Coder le narcissisme :)
Bien que MFC et beaucoup de logiciels écrits pour Windows utilisaient la convention "C" pour les classes, vous ne trouvez généralement pas ce dernier dans le logiciel écrit pour les plates-formes UNIX. Je pense que c'était une habitude très fortement encouragée par Visual C ++. Je me souviens que Visual C ++ 6.0 préfixerait un "C" à toutes les classes que l'on crée avec l'assistant de classe.
voir ici: http://www.jelovic.com/articles/stupid_naming.htm < / a> pour un long article sur cette question.
Ces conventions pour variables sont utiles pour des langues comme Fortran où vous n'avez pas besoin de déclarer les types de vos variables avant de les utiliser. Je semble rappeler que les variables qui sont des noms de «I» ou «J» par défaut sur les entiers et les variables qui ont commencé avec «R» et d'autres lettres défaillaient des valeurs réelles (flottantes).
que les gens utilisent des personnes similaires pour les langues dans lesquelles vous devez déclarer des variables - ou pour les définitions de classe - est probablement simplement une relique de quelqu'un mal compris les conventions de code d'anciennes conventions à partir de langues comme Fortran où elle compte en fait.
Lors de la rédaction d'applications utilisant les bibliothèques QT, nous utilisons une convention de dénomination qui distingue les classes directement ou indirectement de QOBJECT des classes qui ne sont pas. Ceci est utile car vous pouvez dire au nom de la classe si elle prend en charge des signaux / emplacement, des propriétés et de toutes les autres friandises provenant de QOBJECT.
Personnellement, je trouve que la notation hongroise m'aide, en ce sens que je peux regarder un écran plein de variables et savoir instantanément ce qu'ils sont comme je m'essaye et absorber la logique. Votre seul argument contre celui-ci, je vois est "Typage supplémentaire"
Tout ce que je sais, c'est que je suis heureux d'avoir répandu avec des conventions de nommage .net :)