Discussion :

[Emmanuel Delahaye]

Comment justifier qu'on definisse des variables quand on ne peut pas les initialiser avec une valeur pertinante?

Ca c'est très juste et c'est-ce qui me gonfle avec le Pascal.

[Thierry Chappuis]

ce que je voulais dire, c'est que :

tu fais une fonction qui, par définition, effectue une certaine opération.

Que tu aies suivi ou non une démarche écrite spec / conception préliminaire / conception détaillée ou que tu le fasses de tête, je ne vois pas comment tu peux (même en pseudo-code) justifier que tu fais :

je rentre dans la fonction
je fais une opération
je déclare un certain nombre de variables
je fais cette 2ième opération
je déclare d'autres variables
etc..

Que le langage le permette c'est une chose. Que cela soit utilisable c'en est une autre..

Personellement de toutes façons mon principal argument est la lisibilité (même chose d'ailleurs, sauf cas très spécifiques principalement de debug, pour les variables locales dans des accolades au milieu des routines)

J'ai eu entre les mains des codes comme ça à intégrer et à sécuriser, ben souvent tu t'arraches les cheveux un bon moment avant de comprendre ce que ça fait, car le problème c'est que souvent c'est l'ensemble des "mauvaises" manières qui sont associées (le problème étant l'utilisation par un hacker et non par quelqu'un ayant une discipline) : include se baladant au milieu du fichier, variables locales statiques, variables globales définies entre routines, commentaires du style " I know it shouldn't work for everything but it works for me", etc.....

En ce qui me concerne également, le standard de fait en matière de langage C est C90 (mais comme le dit Emmanuel, c'est matière à disucussion). Je déclare donc mes variables en début de bloc lorsque je programme en C. Toutefois, lorsque je programme en C++ où le standard en vigueur autorise plus de liberté au niveau de la déclaration des variables, je préfère définir ces variables juste avant leur utilisation afin de les initialiser à une valeur qui fait sens. De plus, cette manière de faire permet de déclarer les variables dont la valeur n'est pas destinée à être modifiée avec le qualificatif const. Cela ne me choque pas si quelqu'un pratique de la sorte en C99, du moment que cela correspond à ses objectifs de portabilité.

Thierry

[souviron34]

Ouh là !! j'ai provoqué un tollé....

Je fais ça tout le temps dans des blocs selon le principe "la portée d'un objet est réduite au minimum utile". As-tu lu le code ma bibliothèque ? D'après ton expérience, est-ce bizarre, illisible, tordu, illogique, mal conçu ? Ou simplement inhabituel par rapport à ta façon de coder ?

Je n'ai pas parcouru toute ta lib, mais ce que j'en ai vu ne m'a pas présenté de telle utilisation...

Mais si ça existe, je persiste à dire que c'est plus difficilement lisible... (et portable vers un autre langage. Mais il faut dire que mon expérience est avec des progammeurs/utilisateurs scientifiques, et que en gros les portages sont entre C, Fortran, Prolog, et Pascal)

Pour justifier des variables hors début de bloc, je ne dirais qu'un mot : const

C'est une implémentation. Je ne vois pas en quoi c'est une justification.

Comment justifier qu'on définisse des variables quand on ne peut pas les initialiser avec une valeur pertinente?

Quand dans une spécification fonctionnelle tu définis une interface de fonction, tu te fous pas mal de l'initialisation. Tu sais simplement que tu auras besoin de telle et telle variable.

Il me semble donc logique que lorsque je rentre dans une fonction, je sache que je vais avoir à utiliser l'ensemble de ces variables.
Quand je vais construire une pièce dans une maison, je préfère réfléchir un bon coup avant, calculer, et aller acheter en une seule fois le sable, le ciment, les briques, le plâtre, dans les quantités dont j'aurais besoin, parce que ça fait partie de la conception de la pièce, plutôt que d'y aller au coup par coup, parce qu'au milieu d'un mur j'ai plus de ciment ou plus de briques..

Et enfin je n'ai jamais dit que ce n'était pas faisable, juste que je ne trouve pas ça très lisible en C. Que cela se fasse en C++, aucun problème.

[Amybond]

Merci a tous

[Emmanuel Delahaye]

Je n'ai pas parcouru toute ta lib, mais ce que j'en ai vu ne m'a pas présenté de telle utilisation...

Par exemple, pour rester dans des domaines connus...

http://emmanuel-delahaye.developpez....ib/ed/src/io.c

Mais si ça existe, je persiste à dire que c'est plus difficilement lisible... (et portable vers un autre langage. Mais il faut dire que mon expérience est avec des progammeurs/utilisateurs scientifiques, et que en gros les portages sont entre C, Fortran, Prolog, et Pascal)

Ou la, si il faut commencer à écrire du code compatible avec les autres langages, on a pas fini. Heureusement, il existe des passerelles qui permettent de mélanger des fichiers objets écrits en différents langages, ce qui rend cette manip inutile...

Quand on fait une DLL en C, on se fout pas mal de savoir si les fonctions vont être appelées en C, en Java , en assembleur ou en Haskell (je ne sais pas ce que c'est mais, ça fait savant...)...

Par contre, on a scrupuleusement respecté les règles qui permettent de générer une ABI correcte et compatible, et l'usage des flottants et autres chaines est strictement documenté.

Quand dans une spécification fonctionnelle tu définis une interface de fonction, tu te fous pas mal de l'initialisation. Tu sais simplement que tu auras besoin de telle et telle variable.

Il n'y a absolument aucun rapport entre l'interface et les variables locales et leur éventuelle initialisation.

Une variable locale, ça fait un travail le plus local possible. En principe, je déclare, je définis et j'initialise en une fois, et la variable est détruite en fin de bloc.

Je ne vois pas ce que ça a d'illisible, au contraire. Les variables locales sont plus(plusse) liées à des contraintes d'implémentation qu'à une signification fonctionnelle précise (sauf valeur de retour). D'ailleurs, la variable qui contient la valeur de retour est généralement définie en première ligne de la fonction. Logigue...

Code :

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

1
2
3
4
5
6
7
8
9
 
int f (...)
{
   int ret = 0;
 
   /* n'importe quoi qui peut éventuellement altérer ret. */
 
   return ret;
}

[Médinoc]

C'est une implémentation. Je ne vois pas en quoi c'est une justification.

1. Marquer en début de bloc ou non, c'est de l'implémentation.
2. Const est une justification car il y a des variables qu'on ne peut pas initialiser au début d'un bloc. Et une variable const ne peut être qu'initialisée.
   Donc, il y a des variables qui ne sont affectées qu'une seule fois dans toute leur portée et qui ne peuvent être const que si elles ne sont pas déclarées en début de bloc.

[Jean-Marc.Bourguet]

Quand dans une spécification fonctionnelle tu définis une interface de fonction, tu te fous pas mal de l'initialisation.

De l'initialisation de quoi? Tu ne me parles que d'interface ici, alors que le sujet sont les variables de bloc qui n'apparaissent pas a ce stade de spécification chez moi.

Tu sais simplement que tu auras besoin de telle et telle variable.

Non. A la rigueur tu as une idee d'un sous-ensemble des variables que tu vas utiliser, mais tu ne les connais pas toutes. Et ca n'apparait pas dans la spec qui n'atteint pas ce niveau de description.

Il me semble donc logique que lorsque je rentre dans une fonction, je sache que je vais avoir à utiliser l'ensemble de ces variables.
Quand je vais construire une pièce dans une maison, je préfère réfléchir un bon coup avant, calculer, et aller acheter en une seule fois le sable, le ciment, les briques, le plâtre, dans les quantités dont j'aurais besoin, parce que ça fait partie de la conception de la pièce, plutôt que d'y aller au coup par coup, parce qu'au milieu d'un mur j'ai plus de ciment ou plus de briques..

Pour autant que l'analogie vaille quelque chose, les variables me semblent plus correspondre aux outils qu'aux materiaux. Et quand je demande a un macon de me contruire un mur, je ne lui indique pas que je veux qu'il utilise deux truelles, un fil a plomb et une betonniere -- immobilise celle-ci tant qu'il est toujours dans la phase de demolition n'est d'ailleurs pas tres sense. Et s'il a un aide qui vient temporairement et qu'il y a une truelle de plus, ca n'a pas d'importance pour moi tant que les specs du mur sont respectees et qu'il n'oublie pas le ferraillage qu'il a facture :-)

Et enfin je n'ai jamais dit que ce n'était pas faisable, juste que je ne trouve pas ça très lisible en C.

En C j'ai le probleme de la portabilite. J'utilise encore des compilateurs C90. Introduire des blocs est un plus lourd et on se retrouve devant des choix ou parfois introduire un bloc est mieux, parfois declare la variable sans pouvoir l'initialise est mieux.

De toute facon, s'il y a une grosse difference de lisibilite, c'est signe qu'il faut regarder s'il ne faut pas decouper le bloc. Et quand on le fait, avoir les variables plus localisees aide a la decoupe.

[gl]

Ensuite, le fait que je préfère que le type soit déclaré en début de bloc est une affaire personnelle et liée à la portabilité (pour moi, le standard de fait, c'est C90, mais les avis divergent sur ce point).

Je partage ta preference car :
* C'est davantage portable.
* Il plus facile de voir a quel bloc la variable appartient et donc le code est davantage lisible.
* ll est generalement plus long de trouver une instruction au milieu de declaration de variable (enin pour moi).
* En outre, sauf cas particulier, je ne vois pas le gain apporte par la declaration de variables apres des instructions[1].

Selon ces criteres, je trouveque l'organisation du code utilise par le PO dans le message incrimine ne correspond a de "bonnes habitudes de programmations" (c'est un avis certes assez subjectif).

Dans le meme registre, je reprocherais au code du PO l'utilisation de

Code :

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

double valeur1, valeur2;

Je trouve assez peu lisible de declarer deux varaibles sur la meme ligne, mais la encore ca reste une question de gout.

Pour justifier des variables hors début de bloc, je ne dirais qu'un mot : const.

Comme pour toute regle, il y a des exceptions[2].




[1] Hors instructions utilisees pour intialiser des variables. En clair

Code :

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

FILE* fp=fopen(...)

ne me gene pas. Par contre, je ne vois pas ce qu'apporte l'ecriture

Code :

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

1
2
srand(...)
FILE* fp;

[2] D'ailleurs, a mon humble avis, la premiere regle de tout documents "regles de programmation" devrait specifier que toutes les regles qui suivent peuvent, si il existe une bonne raison et que c'est correctement documente, etre enfreinte.

[souviron34]

[2] D'ailleurs, a mon humble avis, la premiere regle de tout documents "regles de programmation" devrait specifier que toutes les regles qui suivent peuvent, si il existe une bonne raison et que c'est correctement documente, etre enfreinte.

100% d'accord.. Et c'est d'ailleurs vrai aussi pour les normes....

[David.Schris]

[...] Mais dans d'autres langages, au contraire (BASIC, Python, Ruby etc.), il n'y a pas de définition préalable. C'est le type de la partie droite de l'affectation qui détermine le type de l'objet crée (typage dynamique).

Code :

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

1
2
3
4
 
   i := 2        ; creation d'un entier
   j := 1.2     ; creation d'un reel.
   k := "hello" ; creation d'une chaine etc.

évidemment, la lecture d'une variable n'ayant jamais été affectée (donc créée) entraine une erreur d'exécution (variable inconnue).

Pas avec tous les langages.

[Thierry Chappuis]

Pas avec tous les langages.

Tu peux citer des exemples???

Thierry

[Jean-Marc.Bourguet]

Tu peux citer des exemples???

Au moins BASIC, Perl

[Ksempac]

Personnellement je prefere la méthode C99/C++.
Je trouve que déclarer en début de code, en plus du probleme d'initialisation deja évoqué, ca obscurcit les déclarations. En effet, on se retrouve a faire des déclarations de variables "facultatives/sans véritable sens" (notez les guillemets) et on est obligé de compenser en rajoutant des commentaires.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
int mafonction()
{
/*Iterateurs pour les boucles for imbriquées*/
int i;
int j;
/*variable temporaire de traitement dans la boucle for*/
char temp;
/*Variables vraiment utiles*/
//declaration des variables ayant de véritables informations
//tout un tas de lignes de code
...
for(i;i<max;i++)
{
   for(j;j<max;j++)
   {
    ...
   }
}
}

au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int mafonction()
{
//declaration des variables ayant de véritables informations
//tout un tas de lignes de code
...
 
for(int i = 0;i<max;i++)
{
   for(int j = 0;j<max;j++)
   {
    char temp;
   }
}
}

De plus, on doit sans cesse se referer au début des fonctions lorsqu'on recherche le nom/type d'une variable meme si elle n'est utile que dans un sous-bloc.

[Thierry Chappuis]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int mafonction()
{
//declaration des variables ayant de véritables informations
//tout un tas de lignes de code
...
 
for(int i = 0;i<max;i++)
{
   for(int j = 0;j<max;j++)
   {
    char temp;
   }
}
}

De plus, on doit sans cesse se referer au début des fonctions lorsqu'on recherche le nom/type d'une variable meme si elle n'est utile que dans un sous-bloc.

On est d'accord, mais cette syntaxe de la structure de contrôle for n'est pas supportée par tous les compilateurs, en particulier ceux qui n'implantent pas ou de manière incomplète la nouvelle norme du langage (C99).

Thierry

[Ksempac]

Si cette boucle for n'est pas prise en charge, on peut aussi utiliser cette syntaxe, qui est tout aussi claire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int mafonction()
{
//declaration des variables ayant de véritables informations
//tout un tas de lignes de code
...
int i;
for(i = 0;i<max;i++)
{
    int j;
    for(j=0;j<max;j++)
    {
    char temp;
    ...
    }
 
}

Inutile de rajouter un commentaire pour expliquer le but de i et j, et les déclarations des variables utiles (en début de bloc beaucoup plus haut) n'ont pas été "polluées".

[Thierry Chappuis]

Au moins BASIC, Perl

Merci! J'avais mal saisit à quoi se rapportait la remarque de David.Schris (erreur d'exécution)

Thierry

[Thierry Chappuis]

On peut aussi utiliser cette syntaxe, qui est tout aussi claire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
int mafonction()
{
//declaration des variables ayant de véritables informations
//tout un tas de lignes de code
...
int i;
for(i = 0;i<max;i++)
{
    int j;
    for(j=0;j<max;j++)
    {
    char temp;
    ...
    }
 
}

Inutile de rajouter un commentaire pour expliquer le but de i et j, et les déclarations des variables utiles (en début de bloc beaucoup plus haut) n'ont pas été "polluées".

et tout aussi peu portable... Mais suis d'accord que suivant les objectifs de portabilitérecherchés, cette pratique est recommendable et rend le code plus lisible.

Dans ce cas, je préfère:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
{
    int i;
    for(i = 0;i<max;i++)
    {
        int j;
        for(j=0;j<max;j++)
        {
            char temp;
            ...
        }
    }
}

Mais je déclare en général mes compteurs de boucles en début de routine lorsque je me limite à C90.

Thierry

[souviron34]

mais je rajouterais un clin d'oeil .... parce que je n'ai jamais utilisé....

Si tu as besoin de plusieurs fois ce i (c'est à dire tu as plusieurs bloucles séparées par du code), comment ça se passe ? tu re-déclares à chaque fois ? ça doit augmenter la taille de la routine alors non ??

[Thierry Chappuis]

mais je rajouterais un clin d'oeil .... parce que je n'ai jamais utilisé....

Si tu as besoin de plusieurs fois ce i (c'est à dire tu as plusieurs bloucles séparées par du code), comment ça se passe ? tu re-déclares à chaque fois ? ça doit augmenter la taille de la routine alors non ??

pourquoi?

Thierry

[souviron34]

pourquoi?

Thierry

je pose la question. Si tu déclares dans une boucle

Code :

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

1
2
 
for ( int i = 0 ....)

Est-ce que cette déclaration est valable plus loin (à l'extérieur de la boucle) ?
Et sinon, si j'ai bsoin d'une autre boucle plus loin et que je re-fais :

Code :

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

1
2
 
for ( int i = 0 ....)

Est-ce que ça ne me prend pas 2 int dans la fonction ???