Discussion :

[ginchen]

J’ai eu une discussion avec un collègue qui prétend que déclarer les variables ailleurs qu’en début de fonction en C++ (éventuellement au début d’un bloc) est une mauvaise pratique.

Cela réduirait la compressibilité du code et serait même incompatible avec certains compilateurs.

Qu’en pensez-vous ?

[Invité]

Qu’en pensez-vous ?

qu'il a gardé ses vieux réflexes de codeur C...


si le code est bien organisé, non, ca ne réduit pas la lisibilité... mais bon, la qualité, c'est un tout. il ne suffit pas de nommer les variables au bon endroit si on leur donne un nom pourri et qu'on ne les initialise pas d'un autre coté par exemple...

[Eusebe]

Regarde cette discussion :
http://www.developpez.net/forums/sho...d.php?t=215405

Notemment à partir du post 7...

[Ti-R]

qu'il a gardé ses vieux réflexes de codeur C...

On dirait.

Cela réduirait la compressibilité du code et serait même incompatible avec certains compilateurs.

Le C++ permet de le faire, ce qui est bien pratique comparé au C, pas d'incompatibilité connue.

Bienvenu sur le forum www.developpez.net en tout cas

[Jean-Marc.Bourguet]

J’ai eu une discussion avec un collègue qui prétend que déclarer les variables ailleurs qu’en début de fonction en C++ (éventuellement au début d’un bloc) est une mauvaise pratique.

Je pense exactement l'inverse: définir des variables ailleurs qu'à l'endroit où on peut les initialiser de manière sensée alors qu'on pourrait le faire est une mauvaise pratique.

Cela réduirait la compressibilité du code

Je ne comprends même pas l'argument. Ce que je comprends ne me semble avoir aucun rapport.

et serait même incompatible avec certains compilateurs.

C'est autorisé en C++ depuis au moins 1984... je doute qu'il y ait des compilateurs qui ne le supporte pas. (Ce n'est pas possible en C90 mais bien en C99, c'est peut-être ce qui induit ton collègue en erreur?)

[ginchen]

Merci pour vos réponses, ça va dans le sens de mon opinion, mais devant la conviction de mon collègue, je préférais avoir d’autres avis.

[Graffito]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
J’ai eu une discussion avec un collègue qui prétend que déclarer 
les variables ailleurs qu’en début de fonction en C++ 
(éventuellement au début d’un bloc) est une mauvaise pratique.

Déclarer ensemble toutes les variables dans la même zone en début de foncion améliore la lisibilité du code. J'aurais tendance à être 100% d'accord avec ce collégue, d'autant plus qu'il admet d'éventuelles déclarations en début de bloc. Il faut penser à ce que le code peut être partagé avec des personnes qui justement pratiquent de la sorte.

D'ailleurs, Pascal (et delphi) imposent cette "bonne" pratique.

[Invité]

donc si je résume Graffito, t'es un Codeur C !?

[Jean-Marc.Bourguet]

Déclarer ensemble toutes les variables dans la même zone en début de foncion améliore la lisibilité du code.

S'il y a une différence de lisibilité (dans un sens ou dans l'autre), c'est que la fonction est trop grande.

Mettre les définitions aux endroits où on peut faire l'initialisation est tout d'abord obligatoire pour certaines classes qui n'ont pas de constructeur par défaut.

Mettre les définitions aux endroits où on peut faire l'initialisation permet de mettre plus de variables const. Ce qui est une bonne chose.

Mettre les définitions aux endroits où on peut faire l'initialisation et retarder celle-ci au maximum, c'est garder les définitions proches des utilisations et préparer la découpe de la fonction quand elle aura grossit. On n'aura pas alors à chercher si une variable est utilisée dans le bloc qui précède et si c'est bien pour le même usage.

[Graffito]

Bonjour,

Je suis un codeur C++ occasionel et un codeur Delphi régulier. Je participe parfois à la maintenance de code C++ et je suis personellement géné par des déclarations non regroupées.

Mais, j'ai aussi constaté que lors de debuging avec les créateurs du code que le fait de disséminer les variables arrivait à masquer des anomalies/problèmes que l'on aurait pu détecter plus facilement si les déclarations de variables avaient été regroupées.

Toutefois, je conçois que les avis puissent diverger sur le sujet et les arguments de Jean-Marc Bourguet sont parfaitement recevables.

En fait, la discussion révéle indirectement un des défauts de C et C++ : pas de fonction locale à l'intérieur d'une fonction.

[loufoque]

Déclarer une variable appelle son constructeur, puis faire un assignement appelle son opérateur d'assignement.
Alors que si on l'initialise direct, on fait simplement un appel au constructeur.
De plus des types ne supportent pas l'assignement et nécessitent d'être construits avec des paramètres appropriés.

Bref déclarer en début de bloc, c'est uniquement possible pour les types de base.

[Graffito]

Bonjour,

Déclarer une variable appelle son constructeur, puis faire un assignement appelle son opérateur d'assignement.
Alors que si on l'initialise direct, on fait simplement un appel au constructeur.
De plus des types ne supportent pas l'assignement et nécessitent d'être construits avec des paramètres appropriés.

Bref déclarer en début de bloc, c'est uniquement possible pour les types de base.

La position de la déclaration/initialisation n'impacte en rien le codage ou le fonctionnement (à part l'allocation mémoire qui peut se faire plus ou moins tôt).

[loufoque]

La position de la déclaration/initialisation n'impacte en rien le codage ou le fonctionnement (à part l'allocation mémoire qui peut se faire plus ou moins tôt).

Apparemment, tu sais pas ce qu'est un constructeur.

[Luc Hermitte]

La déclaration "anticipée" n'est possible qu'avec les données default-constructibles comme le dit loufoque. Détestant particulièrement les mutateurs publics et autres fonctions init(), j'interdis aussi régulièrement les constructeurs par défaut.

Je suis à 200% derrière Jean-Marc. Ses remarques sont des plus pertinentes.

Dans la catégorie refactorisation, ces fonctions trop longues j'en ai déjà vu de bons paquets. Et à chaque ajout de fonctionnalité/correction de bugs il y a des variables qui changent. Et quand on programme comme des cochons, et en plus que l'on utilise les déclarations en début de fonctions, on se retrouve donc avec des fonctions qui tiennent sur trois pages d'écran : une demi-page pour les variables, une et demi pour les traitements d'exception, et une pour le code effectif). Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations antiticipées c'est génial pour avoir des résidus qui polluent inutilement du code. Bref, c'est vite illisible, plus pénible à refactoriser, ...

Perso, je préfère les fonctions courtes dont le code effectif tient dans des demis pages d'écran (Mes sessions de vim ont des fenêtres splittées dans tous les sens). Avoir les variables construites à leur valeur finale dès la déclaration aide beaucoup à la compréhension des codes AMHA. Spécifier leur non-mutabilité rajoute encore de la précision à ce que l'on veut exprimer -- au fait, pourquoi l'italique Jean-Marc ?

Après j'ai la flemme d'aller chercher le Coding Standard de Sutter & Alexandrescu, je sais qu'ils conseillent la règle de la construction initialisante.

[ep31]

En principe si on code de façon "correcte", on n'a pas besoin de déclarer 36 000 variables ni objets.
Une méthode est censée faire une chose et une seule.
Et déclarer des objets/variables en début de méthode, je trouve que ça n'a aucun intérêt. On déclare et on utilise une variable dans un bloc dont on en a besoin, locale à celui-ci et point barre.
Ce n'est pas le fait de situer une variable ici ou là qui rend le code illisible mais une méthode qui fait à la fois la café, qui lance la machine à laver, va chercher les courses, lance une alerte s'il y a trop de vent ....

[koala01]

Salut,

Je dirais que le fait de déclarer les variables en début de fonction *peut* avoir, quand on débute, une coté "sécurisant" pour le programmeur:

Apres tout, s'il oublie le nom d'une variable, il n'a qu'à aller voir le début de la fonction, et il est sur de trouver la liste de toutes les variables déclarée...Mais... C'est sans doute un mauvais calcul à long terme.

D'un autre coté, avoir une variable déclarée, c'est pas mal, mais avoir une variable initialisée, c'est encore mieux

Or, si l'on garde le pli de délcarer toutes les variables en début de fonction, il risque d'y en avoir plusieurs dont on ne peut pas prévoir, dés ce moment là la valeur qu'il faudra leur donner pour les initialiser...

On *peut* donc envisager de leur donner des valeurs par défaut, mais cela impliquera que l'on doive à chaque fois vérifier (ou presque) que la variable a été modifiée/initialisiée avec une valeur utilisable avant de l'utiliser... et ca finira par faire une fonction perclue de tests ou de blocs try...catch.

De plus, imaginons simplement une classe qui contitendrait une std::list<untype> et une std::map<unautretype>, et que la fonction doive boucler, d'abord sur les éléments de la liste, puis sur les éléments de la map...

On se trouvera, si l'on veut déclarer les variables en début de fonction, dans l'obligation de déclarer un itérateur sur la liste, avec son nom propre, et un autre sur la map, avec son nom propre également (sous peine d'avoir une redéclaration de variable)...

Alors que le fait de déclarer les variables au moment où elles sont utiles permet d'utiliser, un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
// tout ce qui précede
for(std::list<untype>::iterator it=MaListe.begin();it!=MaListe.end();it++)
{
    const std::string chaine="laliste";
    //la gestion de la liste en utilisant it
}
for(std::map<unautretype>::iterator it=MaMap.begin();it!=MaMap.end();it++)
{
    const std::string chaine="lamap";
    //la gestion de la map en utilisant it
}

qui peut s'avérer plus lisible et plus cohérent... it et chaine n'existant que dans la portée tres précise de la boucle dans laquelle il sont utilisés...

Et, de fait, si l'on décide de placer ces deux boucles dans des fonctions séparées, on sera sur, en faisant un simple couper/coller des boucles de partir avec toutes les variables dont les boucles ont besoin

Le C++ permet la déclaration ailleurs qu'avant la premiere instruction, introduisant un concept de "variable super locale" (à un bloc d'instructions), autant en profiter... les compilateurs actuels sont en mesure d'en tirer le meilleur parti

Sans compter que le fait de déclarer une variable au moment de son utilisation limite quand meme fortement le risque... d'en oublier son nom non?

[Duarna]

Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations anticipées c'est génial pour avoir des résidus qui polluent inutilement du code.

Je ne suis pas d'accord. Il est très simple d'éviter les variables non-utilisées, un compilateur bien réglé voire un peu parano les signale.

[Luc Hermitte]

Dans l'absolu certes. Sauf quand on ne peut pas choisir le compilateur avec lequel on travaille.

[koala01]

Excuses moi, Duarna, mais, j'aimerais que tu aie l'honneteté intellectuelle de ne pas prendre une phrase completement sortie de son contexte comme base de dénégation.

Bien sur, il est tout à fait vrai que le réglage adéquat du compilateur permet de retrouver les variables inutilisées, et parfois meme les variables non initialisées...

Mais la phrase de luc que tu site prend un sens tout à fait différent si tu la laisse dans le contexte complet:

Et quand on programme comme des cochons, et en plus que l'on utilise les déclarations en début de fonctions, on se retrouve donc avec des fonctions qui tiennent sur trois pages d'écran : une demi-page pour les variables, une et demi pour les traitements d'exception, et une pour le code effectif). Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations antiticipées c'est génial pour avoir des résidus qui polluent inutilement du code. Bref, c'est vite illisible, plus pénible à refactoriser, ...

Bien sur, la déclaration anticipée ne représente "qu'une goutte d'eau" dans la somme des problèmes que l'on peut rencontrer (dont la plupart sont souvent liés plus à la "non initialisation" qu'à la non utilisation).

Mais le sens de l'intervention de luc est que, si tu rajoute cette goutte d'eau à une série d'autres comportement "à risque" (allant de la mauvaise indentation/mise en forme à une taille excessive pour l'affichage du code de la fonction en passant par du code trop alambiqué, à force de "raccourcis" offert par le langage ou l'ajout de possibilité/le débuggage), la difficulté avec laquelle tu t'y retrouveras dans le code est bien plus que la simple addition de toutes les (petites) difficultés que chaque comportement implique... mais plutot de l'ordre de l'exponentielle des différentes difficultés

Mais, là, on aborde plus le problème des "bonnes" habitudes de programmation que le simple problème d'une déclaration anticipée.

Ainsi, cette simple ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

membre=methrode1(methode2(methode3(methode4(), methode5())));

est, susceptible d'etre tout à fait valide si les types de retours correspondent aux type des arguments attendus par les différentes méthodes...

Mais il n'empeche que, meme avec des noms de méthodes "auto-commentée" (AKA dont on retrouve l'action effectuée dans le nom) la ligne présentera une difficulté de lecture bien suppérieure au code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
type1 val=methode5();
type2 val2=methode4();
type3 val3=methode3(val2);
type4 val4=methode2(val3);
typefinal=methode1(val,val4);

qui fournira pourtant un résutlat tout à fait identique, et pas forcément plus lent à l'exécution - avec, bien sur,les types et les noms de méthodes/variables cohérents.

Je sais qu'il n'est pas forcément courent d'avoir besoin de 5 ou de 6 fonctions pour déterminer la valeur d'un seul élément... mais, en C, par exemple, un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
FILE *fichin,*fichout;
if((fichin=fopen("monfich","r"))!=NULL && (fichout=fopen("fichcopy","w"))!=NULL)
{
   //blabla
}

est tout à fait valide... (si du moins, je n'ai pas fait d'erreur de parentheses, car je ne l'ai pas retesté avant de l'écrire )

Il n'empeche que, la première fois que j'ai croisé cette syntaxe (j'étais débutant en C) j'ai eu un certain mal à comprendre le sens des tests et j'ai du recompter plusieurs fois le nombre de parentheses présentes pour etre sur de en pas en oublier...

Un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
FILE *fichin=fopen("monfich","r");
FILE *fichout=fopen("fichcopy","w");
if(fichin!=NULL && fichout!=NULL)
{
    //blabla
}

aurait eu le meme résultat, mais avec la lisibilité en plus..et le risque de mauvaise compréhension/d'erreur en moins...

Et pourtant, en nombre de touches de clavier enfoncées (espaces et touche <ENTER> inclus) il n'y a qu'une différence, si j'ai bien compté, de trois touches

Ayant appris la dactylographie, et "tapant" plus ou moins 60 mots de 8 lettres à la minutes, le deuxième code m'aurait pris... moins d'une demi seconde en plus à écrire

Crois tu réellement qu'en cas d'erreur dans le premier code (une simple parenthese mal placée ou oubliée, par exemple) j'aurais mis moins d'une demi seconde pour repérer et corriger l'erreur

Et, faut il rappeler qu'une parenthese fermante est le genre d'erreur - avec la faute d'orthographe dans un nom de fonction ou de variable - le plus facile à situer, à repérer et à corriger parce qu'apparaissant dés la compilation...

Mets l'un de ces codes dans une fonction de 100 lignes, rajoute quelques déclarations anticipées de variables (sans les définir au départ) ou oublie de tester si la fin du fichier a été atteinte avant d'effectuer une lecture et... amuse toi à retrouver l'erreur à l'exécution

[spawntux]

Bonjour

Je suis tout a fait d'accord avec toi koala .
Mais apres tout depend a quoi est destiné ton code si il tend a devenir de l'open source autant rendre son code claire precis commenté bien indenté afin que tout le monde puisse comprendre celui ci , mais a la limite si le code ne sera lu que par la personne l'ayant ecrit je dirai tant que cette personne si retrouve chacun voix midi a ca porte .