Notation hongroise, pour ou contre ? (limites d'utilisations ?)
 
Le debat est ouvert !

Salut  
moi je suis pour une notation (hongroise ou n'importe laquelle) car le probleme vient toujours des programmeurs qui viennent  travaille par la suite sur un projet et sans une notation precise qui suit une logique il est peut etre plus dur de s'y retrouver dans un code source.

hongroi c'est plus lisible mais on a pas forcement raison ...
(c'est juste pour caser un jeux de mot )
 
moi je trouve ca bien, mais je l'emploi diferrement de la "Windows" et plutot lors de la définition de mes types que dans les variables, le tout en fin de nom de variable (je trouve que c'est plus lisible ...)
 
genre :

 
la seule notation que j'applique assez regulierement aux variables est a base de majuscule et trait de soulignements
 
#define MAXI 10
 
dans les classes, les membres prives sont precedes de "_"
 
dans une fonction, la variable locale qui va etre retournee est suivie d'un "_" (pour dire qu'elle sort ... ) et les variables passees en parametre sont precedees d'un "_" ...
 
mais je le fait dans les grosses fonctions
 
tout ceci est assez courant, par contre j'aimerais savoir ce ke vous pensez de ce style tres particulier que je n'ai jamais croisé
 
soit par exemple ce petit programme tout con (exemple ...):
 

 
si par exemple je veux savoir quel est le plus grand entre 2 restangles de la liste :

 
bon la c'est plutot cherche mais se retrouver avec des lignes plus longues que ca n'est pas dur
dans ces cas je fait ca :
 

 
vous aimez ou au contraire ca vous choque ?
c'est un peu le meme principe que les macros (dans ce cas une macro serait surement mieux)
je l'emploi surtout pour remplacer une tres longue ligne, qui se repete plusieurs fois (le genre avec plein de '->' et de '[...]')
le plus souvent y'a que un seul #define (pas comme ici)
je prefere ca aux macros parceque la on a le #define = a quoi correspond le truc sous les yeux
les macros fo parfois aller les chercher en plein milieu d'un fichier .h de 10000 lignes ...

HelloWorld> Moi je préfère ce qui suit. C'est beaucoup plus sûr, et le code généré est exactement le même voire meilleur avec un bon compilateur (i.e. avec un bon optimiseur de code) :

Pour répondre au sujet du topic, quand je l'ai découverte, la notation hongroise m'a beaucoup plu, mais j'ai complètement changé d'avis depuis. Plusieurs raisons à cela.
 
D'abord, un tel système de conventions ne fonctionne vraiment que s'il est entièrement standardisé au sein d'une équipe de développement (et même au-delà). Qu'une seule personne l'applique légèrement différemment et il perd en lisibilité ce qu'il est censé gagner. Or les équipes qui standardisent leur code jusqu'au nommage des variables sont rares dans l'industrie (je dirais, plus exactement, assez cantonnées à quelques domaines d'applications bien particuliers, genre le spatial, par exemple).
 
Le principal reproche que je ferai à la notation hongroise est qu'en général, elle s'attache au type de la variable (voir les acronymes classiques sous Windows, genre LPCSTR), alors qu'un bon nom de variable doit contenir de la sémantique. On se fout éperdument de savoir qu'un type pointeur soit "long" et qu'il soit constant. C'est le boulot du compilateur de vérifier ça. Par contre, c'est mille fois plus intéressant (et important) de savoir qu'on manipule une date plutôt qu'un nom de personne ou une URL, alors que les 3 sont souvent codés sous forme de chaine de caractères. D'ailleurs, pouvoir définir des types différents pour chacun serait bien plus profitable qu'utiliser la notation hongroise, mais en pratique, j'observe tous les jours que peu de programmeurs le font.
 
Si on suit la règle ci-dessus en matière de nommage (de la sémantique, pas d'informations sur le type), et qu'on s'oblige à écrire des mots entiers (donc pas d'abréviations, qui sont toujours sujets à interprétation), on réalise alors que la notation hongroise est complètement inutile, parce que redondante : le nom de variable contient déjà ce que la notation hongroise pourrait apporter, et contient en plus d'autres informations.

Comme bien souvent, entierement d'accord avec BML.
 
>hongroi c'est plus lisible mais on a pas forcement raison ...
>(c'est juste pour caser un jeux de mot )
 
Comme le celebre coup hongrois au poker (hongrois qu'on gagne, et on perd...)?
A+,

Je suis d'accord avec Biface.
Pour ma part je trouve que le type etant deja indique dans le code, c'est bien la semantique de la variable qu'il faut faire passer... Souvent j'ajoute sa visibilite : une majuscule au debut des membres (Membre) et tout en minuscules pour les locales (locale), comme ca on sait ou aller chercher la declaration, pour les globales je mets une majuscule en initiale et en finale (GlobalE) comme ca on les reperes de loin, mais en generale je n'en ais pas...

Au risque de passer pour un con, c'est quoi la notation hongroise ?        
 
Merci d'avance

mareek a écrit a écrit : Au risque de passer pour un con, c'est quoi la notation hongroise ?           Merci d'avance

c'est une facon de nommer les varaibles en les prefixant par un code incomprehensible sense indique de quel type est la variable.
par exemple LPCSZ pour un Pointeur Long sur Char et String a Zero terminal, ou qq chose dans le genre...

Ok, je vois. Merci de ta réponse.
 
Dans ce cas, d'accord avec Macleod

Hey, j'avais jamais pensé à définir une constante (l'habitude du define ...)
du coup je capte mieux maitenant la diferrence entre #define et const ...
sinon moi aussi la notation hongroise elle me plait pas trop
mettre une tartine de lettres devant un nom je trouve ca pas terrible
moi aussi je prefere appeller mes variables NomUtilisateur au lieu de lpNomUtilisateur ... le "Nom" me fait comprendre que c'est une chaine ...
 
la notation je l'emploie plutot pour le nom des types.
 
Pour en revenir a la standardisation, lors de mon stage j'ai du reprendre un programme qui avait un grand nombre de variables globales de 3 à 5 lettres.
c'est malheureusement apres plusieurs semaines ke je me suis appercu que ces noms a priori horribles suivaient une certaine logique de noation.
du coup ces noms m'ont semble beaucoup + clairs et explicites.
donc c'est vrai que utiliser un style de notation sous entends informer le lecteur de la notation apportee
de meme que l'on trouve dans un dictionnaire la signification de tous les accronymes genre "forum : nm, ..." j'ai pris l'habitude suite a ce stage de fouttre une dizaine de lignes qq part dans le source de mon projet qui fait comprendre la notation utilisee

pourquoi Carmack ne l'utilise pas?

Carmack l'utilise
c'est d'ailleurs via les sources de Q3 que j'ai decouvert cette notation
 
typedef ... nom_t;
struct nom_s;
 
etc ...
et ca m'a vachement plût (source hyper comprehensible et lisible)
 
BifaceMcLeOD> j'ai reouvert mes sources pour remplacer mes #define par des const ... helas, c'est pas possible
j'ai oublie de dire que c'etait du C, du pur C et ton "&" a la fin m'avait echapé
et aussi j'utilise pas mal de mini macros
   #define R(x) ecran.rectangle[num_rect##x].dimensions
par exemple dans ce cas
  et donc R(1).L   ou R(2).L
 
du coup je ne comprend toujours pas l'utilite du const en C
c'est quoi la difference entre un #define et un const
en plus j'ai lu que certains compilateurs traitaient les const comme des #define
et a y reflechir je trouve ca mieux : pourquoi réserver de la memoire a une variable alors que celle-ci ne varie jamais (je parle seulement pour des nombres, qui peuvent etre directement remplace dans le code machine et pas pour une chaine de caractere par exemple)
 
etant donné que tres souvent les const sont en debut de fichier, comme les #define, c'est kifkif non ?
 
 
sinon BifaceMcLeOD je n'ai pas testé ta méthode, mais a y reflechir elle me semble un peu limite
si dans mon code je fais :
 
R1.Y = 10;
 
je vais pas avoir un warning, ou meme carrement une erreur de compilation ?
parce que je modifie un objet normalement constant ...
 
d'ailleurs a ce sujet j'ai y'a pas tres longtemps decide de me mettre doucement au C++
et je decouvre les pointeurs constants ...
 
comment le compilateur fait-il pour garantir que mon objet pointe ne sera pas modifie ?
 
exemple :
 
void Bidon(const rectangle_t * Rect)
{
    Rect->X = 10;
}
 
si j'ai bien compris, ca le compilo il tilt et me dit "tu peux pas"
 
mais si :
 
void Bidon(const rectangle_t * Rect)
{
    rectangle_t * Rect2;
 
    Rect2 = Rect;
    Rect2->X = 10;
}
 
comment il s'en appercoit la le compilo ?

HelloWorld a écrit a écrit : ....... BifaceMcLeOD> j'ai reouvert mes sources pour remplacer mes #define par des const ... helas, c'est pas possible j'ai oublie de dire que c'etait du C, du pur C et ton "&" a la fin m'avait echapé et aussi j'utilise pas mal de mini macros    #define R(x) ecran.rectangle[num_rect##x].dimensions par exemple dans ce cas   et donc R(1).L   ou R(2).L   du coup je ne comprend toujours pas l'utilite du const en C c'est quoi la difference entre un #define et un const en plus j'ai lu que certains compilateurs traitaient les const comme des #define et a y reflechir je trouve ca mieux : pourquoi réserver de la memoire a une variable alors que celle-ci ne varie jamais (je parle seulement pour des nombres, qui peuvent etre directement remplace dans le code machine et pas pour une chaine de caractere par exemple)   etant donné que tres souvent les const sont en debut de fichier, comme les #define, c'est kifkif non ?

Entre autre ca permet de les passer par adresse et de leur donner un type.

 
si c comme ca la not hong ok  
pour moi la not hong c ca et trouve pas ca super (d'ailleur carmack ne fait pas ca )
 
int nTruc;
long lMachin;
double dBidul;

HelloWorld> Je m'en doutais que tu écrivais du C plutôt que du C++, et j'ai faill écrire "const dimension_t*  pR1 = &ecran.rectangle[num_rect1].dimensions;", du coup. Moralité : j'aurais du le faire.
 
Pour être franc, j'ai horreur des macros. Le problème du préprocesseur, c'est que contrairement à ce qu'on pourrait croire, il ne connait pas le langage de programmation. C'est un simple outil de remplacement de chaines de caractères, bête et stupide. Au cours de ma (pourtant courte) expérience de programmation, j'ai eu régulièrement des bugs dus à une utilisation incorrecte et abusive du préprocesseur C/C++, et ce genre de bugs sont souvent particulièrement tordus. Tout simplement parce que ce que le compilateur compile n'est pas ce que tu lis dans ton éditeur. Et les techniques pour résoudre ces bugs-là sont très particulières, et pas vraiment simples (à première vue en tout cas).
Donc j'utilise le préprocesseur aussi peu que possible. Et je vous conseille de l'utiliser aussi peu que possible.
 
Alors c'est vrai que si tu veux faire des trucs fancy en C, le préprocesseur peut s'avérer la seule solution. Par exemple, un jour, je me suis amusé à écrire un petit framework pour faire de véritables Types de Données Abstraits en C ANSI pur, avec champs et functions privés et tout et tout. Là, c'est clair, sans le préprocesseur, tu es foutu. A la même époque, je me suis aussi amusé à écrire un petit framework pour pouvoir écrire des types ou des fonctions génériques (on utilise le terme de template en C++). Là, idem, tu ne peux rien faire sans le préprocesseur. Et tu dois en utiliser toutes les ressources... (genre le ##, par exemple).
 
Mais quand on a le choix entre le préprocesseur et une autre solution, je préfère la règle tout sauf le préprocesseur, parce que c'est toujours plus lisible.
 
Et si ton compilateur traite le const comme un #define, c'est encore mieux. C'est la preuve qu'il vaut toujours mieux utiliser une écriture plus lisible même si (surtout si) elle a l'air moins optimisée à première vue, parce que le plus souvent, le compilateur est suffisamment intelligent pour optimiser lui-même cette forme apparemment moins optimisée. Souvent même, il arrive à optimiser mieux que ce que tu pourrais le faire à la main dans ton source (par exemple si tu utilises des pointeurs pour parcourir un tableau au lieu d'utiliser des indices classiques) !
 
Aucun surcoût à l'exécution (au contraire), et un source bien plus lisible, ça devrait balayer toute hésitation chez toi de ne pas l'utiliser !
 
De façon générale, on sous-estime beaucoup trop souvent les capacités d'optimisation des compilateurs, et du coup, on sacrifie beaucoup trop souvent l'aspect lisibilité du source, pour essayer de compenser ce qu'on croit être l'incapacité du compilateur à optimiser tel ou tel bout de code.
J'aurais envie de dire "une des règles de base de la programmation, c'est que ton programme s'adresse d'abord à des humains. Accessoirement, il s'adresse aussi à un ordinateur". Parce que s'il s'adressait principalement à un ordinateur, nous programmerions tous en assembleur...
 
PS: gilou>  

[edtdd]--Message édité par BifaceMcLeOD--[/edtdd]

En C et en C++, le "const" fait partie du type. Donc " rectangle_t* " et " const rectangle_t* " sont de type différent. Au même titre que " rectangle_t* " et " dimension_t* ".
 
Donc quand tu vas faire l'affectation :

le compilateur va râler en disant "Type mismatch: cannot assign const rectangle* value to rectangle* value". Mais évidemment, rien ne t'empêche d'écrire:

et là, plus rien ne t'empêchera de modifier la zone mémoire vers laquelle pointe Rect (en utilisant Rect2).
 
En fait, "const", dans un prototype de fonction, c'est une sorte de contrat. Ca veut dire que la fonction en question s'engage à ne pas modifier cette variable ou une des zones mémoire qu'elle pointe directement ou indirectement (si c'est un pointeur sur pointeur). L'engagement est surtout moral puisque, comme on vient de voir, dans la réalité, on peut toujours modifier une variable const.
 
Puisque tu demandais comment ça marche, les compilateurs C et C++ distingue les l-values et les r-values (l et r pour left et right). Une l-value est une expression qui peut se trouver à gauche du signe d'affectation. Une r-value est une expression qui peut se trouver à sa droite. Exemple :

Ici, "y" est une l-value, et "x + 1" est une r-value (ça n'a aucun sens d'affecter une valeur à "x + 1"...)
 
Le principe du const est de dire : une l-value, dès lors qu'elle est de type "const", perd sa propriété de l-value. Ce qui fait qu'on ne peut plus lui affecter de valeur. Et le tour est joué.

thx you thx you pour ces explication
donc c'est bien ce qui me semblait, le const c'est un moyen pour signaler au programmeur qu'il doit pas toucher a un truc, mais ca ne permet pas d'empecher absolument qu'il le fasse
c'est un pacte comme tu dis
sinon pour les macros je suis pas un fan non plus
ce genre de code je l'emploi rarement et a chaque fois je peux te garantir que ca rend plus lisible
imagine un peu : remplacer des expressions 3 fois plus longues que ecran.rectangle[num_rect1].dimensions.L par ce a quoi elles correspondent
cela s'est produit (pour moi) par exemple dans des "conteneurs d'objets" : un objet qui contient un objet qui en fonction d'une de ses variables contient un pointeur vers tel ou tel type etc ... et t'arrives vite a une ligne monstrueuse et c'est justement pour clarifier mon code pour moi et aussi un relecteur que je remplace cette enorme ligne par un simple nom designant a quoi tout ca fait reference
au lieu de passer 1 ou 2 minutes (c'est long !) a se dire : attend : alors ca c'est ca donc ce truc c'est tel machin ... ah non attend .. j'suis perdu la ... ah oui c'est bon  ... pffffiou !
mais je l'ai dit c'est assez exceptionnel
 
pour ton const, le probleme c'est si je fais ca :
 
R1.L = 10;
 
ce qui est souvent le cas (ces fameuse lignes monstruseuses sont du genre :
ecran.rectangle[num_rect1].dimensions.L = ecran.rectangle[num_rect2].dimensions.L + ecran.rectangle[num_rect2].X;
(alors si je rajoute encore uns structure derriere, vous comprenez mieux comment j'arrive a d'enormes lignes)
alors la le compilo (tu semble me l'avoir confirmé) il va pas aimer
et donc la seule solution semble etre un #define ... que l'on soit en C ou en C++
non ? ou alors de forcer le type  
rectangle_t* Rect2 = (rectangle_t*) Rect;
mais ca perd tout son sens
 
je tiens a preciser que je suis pas un fan des macros
je les emplois avec moderation car je connais les gangers que cela represente
dans un tel cas je limite leurs utilisation a quelques lignes (je les defini et "undefini" presque aussitot)
 
le but est d'augmenter la lisibilite !
je suis tres sensible a la clarte de mon code
quand j'ai appris le C j'etais fan de trucs genre
char chaine[4];
if(*chaine++ && *chaine++ && *chaine++ && *chaine++)
 
mais j'ai compris que ca servait a rien : on gagnait rien en vitesse d'execution
 
du coup ajourd'hui je met
if(ptr == NULL)
au lieu de
if(!ptr)
 
c'est pareil mais c'est plus lisible
je vais meme jusqu'a faire
#define && AND
 
pour distinguer le ET logique du ET binaire ...
 
si je fais #define MAX 5
au lieu d'un const, c'est plus par habitude ...
 
je ne passe plus mon temps a essayer d'optimiser mes boucles (bon si un peu : un while au lieu d'un for pour economiser l'affectation d'une variable ... mais la encore ca rend plus lisible)
en effet : on gagne bien plus a optimiser l'algorithme que à optimiser le code
rien de plus frustrant que de tout bien ecrire ses fonctions hyper optimisees, et apres s'appercevoir sue en structurant autrement le programme, on fait mieux ! => et tout devoir balancer
cela dit, optimiser son code en C, je vois pas trop ce que cela veut dire ...
on peut trop gratter ...
sauf des fois avec des astuces genre register mais souvent c'est assez pareil non ?
optimiser son code en C, pour moi ca veut dire optimiser l'algo ... et je crois que c'est pareil pour tous les langages de haut nivo, non ?
 
TheJackal > Carmack utilise un style de notation ... pas la hongroise non
j'ai compris dans ta question "pourquoi il n'utilise pas de style de notation"
et ma reponse a ete oui il le fait ainsi :  
nom_du type_t
nom_structutre_s
etc ...
si je ne m'abuse, ca c'est la "polonaise"
ou alors je confond avec un autre truc
parce que y'a une histoire pour ces styles de notation
je m'en souviens pas trop ... je crois que il avaient pas de parentheses ou j'sais plus quoi sur leur clavier ...
alors pour faire
2+(3*4)y'avait un truc special
2 3 4 * +
 
ou je sais plus quoi ...
quelqu'un le sait (l'histoire) ?

Les calculatrices HP utilisent la polonaise inversee qui permet de se passer de parentheses.
 
le principe est d'entre les termes dans une pile et les operateurs prenent les parametres dans la pile et renvoient le resultat dans la pile
2+3 devient alors 2 3 +
2*(2+3) devient alors  2 2 3 + *
2*2+3 devient alors 2 2 * 3 +
etc...

helloword: oui ok c pas la hongroise (qui est a chier)
 
pour if(ptr == NULL) au lieu de if(!ptr) c question de gout
et pour la notation de carmack je me demande si c utile (surtout si on utilise les classes maintenant. d'ailleur j'espere ke dans les sources de doom3 yen aura parce ke le c tout court c un peu dommage)

vi, doom3 est (sera) en C++
 
ben cette notation pour les types moi je la trouve tres utile
j'ai recupere les sources d'un gros projet
 
nom_c pour les classes
nom_h pour les handle
nom_cp les pointeurs
nom_s pour les strutures
etc ...
 
ben ca aide drolement
 
et pour les sources de Q3, cette notation est aussi tres utile
g_entity
iu_ ...
ai_ ...
sv_ ...
cg_ ...
 
et ca c'est bien de la hongroise (au debut) qui t'informe directement a quoi est rattache la variable : g : physique du jeux, ai : intellignece artificielle (bot), ui : interface, sv serveurs etc ...)

HelloWorld> OK, je vais ré-écrire la fonction en C ANSI pur :

 
Comme tu vois, les différences sont minimes...
Au passage, tu sais pourquoi les concepteurs de C++ ont introduit la notion de référence, avec le signe '&' ? Sans doute parce que sur leur clavier, la touche '*', utilisée pour déréférencer un pointeur, était trop usée !        
 
Plus sérieusement, je suis 100% d'accord avec tes dernières remarques sur la façon d'écrire le code. Simplement, en général, si tu ressens le besoin d'écrire une macro, fais-en plutôt une fonction, même si elle est très courte. "Fonctionnellement", c'est pareil, sauf que la grosse différence entre une macro et une fonction, c'est que la fonction, elle, a des paramètres typés... donc vérifiés par le compilateur. Et tu remarqueras que dans ce que j'ai écrit plus haut, il y a un peu de philosophie objet (les 2 fonctions pourraient très bien être des fonctions-membres d'une classe "Ecran" ).
 
Quand tu dis préférer écrire "if (ptr != NULL)" plutôt que "if (!ptr)", je suis 200% d'accord. Pour Jackal, c'est affaire de goût ; personnellement, je dirais plutôt que c'est écrire son code comme si le langage était plus typé qu'il ne l'est, et améliorer ainsi sa lisibilité. En effet, en théorie, un "if" attend exclusivement une expression booléenne en argument (et pas entière), et l'opérateur "!" est un opérateur qui, au moins en théorie, attend un argument booléen en entré et retourne un booléen. En C++, il aurait comme prototype :

Donc donner un pointeur en argument à cet opérateur viole les règles du typage fort.
 
Mais je sais d'avance que certains programmeurs trouvent que tout cela est du purisme...   C'est pourtant la raison d'être même du typage fort. On ne peut pas ajouter des carottes et des poireaux, des mètres et des pieds, et le typage fort n'est rien d'autre que le moyen que les programmeurs se sont donnés pour permettre une vérification automatique la plus poussée possible, par un programme (le compilateur), de la cohérence des expressions qu'ils écrivent.
 
Sinon, pour le coup des constantes en #define plutôt qu'en "const", il y a un autre problème. En C pur (je ne parle pas de C++), tu ne peux pas déclarer de tableau comme suit:

Ici le compilateur C va râler en disant que la taille de Tableau n'est pas un littéral (c'est-à-dire un nombre en clair). La seule façon d'éviter de dupliquer la taille du tableau codée en dur est d'utiliser une macro ("#define TAILLE 5" ), ce qui blousera le compilateur (pour lui, la taille du tableau sera bien un nombre codé en dur, mais pour toi, elle sera définie en tant que constante par un #define).

[edtdd]--Message édité par BifaceMcLeOD--[/edtdd]

tout s'eclairci ...
 
je souhaite rajouter pour ta fonction que ici mon code etait un exemple
mon probleme c'est pour faire :
 
ecran.rectangle[num_rect1].dimensions = 10;
 
je veux affecter une valeur a une expression tres longue (tres tres)
 
alors creer une fonction pour remplacer une ligne de code dans tout le projet ... mouarf
si y'a ainsi 3 ou 4 proprietes, ca fait 3 ou 4 fonctions supperflues
mais j'ai pris note de ta remarque (on regroupe 2 lignes en 1 fonction )
 
sinon dernier petit style que j'ai oublie et que celui la je trouve hyper utile important augmenteur de lisibilite:
 
g_variable
 
pour une variable globale
 
et sinon je pour optimiser le code, je suis tombe la dessus :
http://www.alrj.org/docs/algo/boucles.html
 
c'est pas ininterressant ...

 
pour moi la notation hongroise est pour une variable et se rapporte a son type.