Discussion :

[p.salvador]

Salut à tous!

Voice c'est deux bout de codes ci-dessous. Ils font la même chose, mais leurs manières d'exécuter le code diffère.
J'aimerais connaître laquelle vous utiliser et pourquoi?

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
while (1)
	{
		printf("Entrer # pour add \n");
		printf("  or 0 pour arrêter: ");
 
		fgets(line, sizeof(line), stdin);
		sscanf(line, "%d", &item);
 
		if(item == 0)
			break;
 
		if(item < 0)
		{
			++minus_items;
			continue;
		}
 
		total += item;
		printf("Total: %d\n", total);
	}

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
21
22
printf("Entrer # pour add \n");
	printf("  or 0 pour arrêter: ");
 
	fgets(line, sizeof(line), stdin);
	sscanf(line, "%d", &item);
 
    while(item != 0)
    {	
		if(item < 0)
			++minus_items;
		else
		{
			total += item;
			printf("Total: %d\n", total);
		}
 
		printf("Entrer # pour add \n");
		printf("  or 0 pour arrêter: ");
 
		fgets(line, sizeof(line), stdin);
		sscanf(line, "%d", &item);
	}

[ternel]

A brule pourpoint, la seconde, parce qu'elle n'utilise ni break ni continue, ni while(1).
Et aussi parce qu'elle permet de différencier la question initiale de la question de relance/rejet

[foetus]

le do-while est plus sexy

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    do {
        printf("Entrer # pour add \n");
	printf("  or 0 pour arrêter: ");
 
	fgets(line, sizeof(line), stdin);
	sscanf(line, "%d", &item);
 
	if (item > 0) {
            total += item;
            printf("Total: %d\n", total);
        } else if (item < 0) {
            ++minus_items;
        }
    } while (item != 0);

[Sve@r]

Bonjour

J'aimerais connaître laquelle vous utiliser et pourquoi?

Avec ce genre de question, tu auras autant de réponses différentes que d'intervenants.
Perso j'utilise la première écriture. Ca factorise la saisie (une seule instruction au lieu de deux) et ça met bien en évidence l'élimination des cas incorrects qu'on supprimera avant d'attaquer le traitement réel.

La seconde écriture est plus "académique". C'est ce qu'on enseigne dans la "old school of programming" dans laquelle les break et continue (et ceux qui les utilisent) sont brûlés vifs comme sorciers. Mais si on l'applique "à fond", dans des cas plus complexes, on se retrouve à écrire le code utile totalement à droite de l'écran ce qui devient assez gênant
Exemple analogue

Code c :

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
21
22
23
24
25
26
27
28
fp=fopen(...)
if (fp != NULL)
{
    tab=malloc(...)
    if (tab != NULL)
    {
        sd=socket(...)
        if (sd != NULL)
        {
              ... code utile qui se retrouvera, si on a d autres ressources à ouvrir, totalement à droite de l écran...
              close(sd);
        }
        else
        {
              printf("Erreur socket\n");
        }
        free(tab);
     }
     else
    {
          printf("Erreur malloc\n");
    }
    fclose(fp);
}
else
{
    printf("Erreur fopen\n");
}

Le même exemple dans la première approche

Code c :

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
21
22
23
24
25
fp=fopen(...)
if (fp == NULL)
{
    printf("Erreur fopen\n");
    return;
}
tab=malloc(...)
if (tab == NULL)
{
    fclose(fp);
    printf("Erreur malloc\n");
    return;
}
sd=socket(...)
if (sd == NULL)
{
    fclose(fp);
    free(tab);
    printf("Erreur socket\n");
    return;
}
... code utille qui reste bien à gauche de l écran ce qui nous laisse beaucoup de place pour écrire...
close(sd);
free(tab);
fclose(fp);

Ceci toutefois amène le minime inconvénient de bien veiller à fermer les ressources ouvertes en cas de soucis, et à cumuler ces fermetures au fur et à mesure qu'on avance.

C'est un inconvénient minime... mais si ça gêne vraiment, on peut alors y pallier par une utilisation astucieuse du "goto" (oui oui, je sais, les ayatollistes vont hurler...)

Code c :

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
21
22
23
24
25
fp=fopen(...)
if (fp == NULL)
{
    printf("Erreur fopen\n");
    goto fermeture;
}
tab=malloc(...)
if (tab == NULL)
{
    printf("Erreur malloc\n");
    goto fermeture;
}
sd=socket(...)
if (sd == NULL)
{
    printf("Erreur socket\n");
    goto fermeture;
}
... code utille toujours à gauche de l écran...
 
fermeture:
if (sd) close(sd);
if (tab) free(tab);
if (fp) fclose(fp);
// Nécessité, bien entendu, d'avoir initialisé fp, tab et sd en début de code...

Hé oui, si un outil existe, alors autant ne pas s'en priver (sans bien sûr entrer dans les extrêmes )...

[ternel]

Rien n'empeche d'avoir un "mélange" des deux:

test-rejet, et séparation de la question et de sa relance pour validation.
Effectivement, je te soutiens sur le refus des if imbriqués.

[p.salvador]

Avec ce genre de question, tu auras autant de réponses différentes que d'intervenants.

Oui, c'est le but! Après je prends ce qui me convient le mieux ! Pour ma part, je suis pour la première manière "old school...". Je la trouve claire et moins équilibriste! Mais, je pense que la deuxième peut service dans des cas particuliers.

Mais heureusement, à chacun sa méthode. C'est ce qui fait la richesse de ce monde, la variété!

[gangsoleil]

La seconde a l'inconvénient de dupliquer le code. Donc je trouve que c'est à éviter.

Sinon, je préfère privilégier une approche do-while dans ce cas.

[Bktero]

Je penche aussi pour la 1ère écriture car elle évite la duplication de code. La première forme serait intéressante si la première question et les suivantes étaient différentes.

Je ne suis pas contre les break / continue et while(1) s'ils servent la lisibilité et évitent la redondance de code.

La solution do / while est bien dans ce cas aussi.

[Médinoc]

Je vois aussi cette alternative:

Code C :

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
21
22
23
24
25
int inputNumber(int* pItem)
{
	char line[20];
	printf("Entrer # pour add \n");
	printf("  or 0 pour arrêter: ");
 
	fgets(line, sizeof(line), stdin);
	sscanf(line, "%d", pItem);
 
	return *pItem;
}
 
...
 
while (inputNumber(&item)!=0)
{
	if(item < 0)
	{
		++minus_items;
		continue;
	}
 
	total += item;
	printf("Total: %d\n", total);
}

[Sve@r]

Je vois aussi cette alternative:

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
int inputNumber(int* pItem)
{
	char line[20];
	printf("Entrer # pour add \n");
	printf("  or 0 pour arrêter: ");
 
	fgets(line, sizeof(line), stdin);
	sscanf(line, "%d", pItem);
 
	return *pItem;
}

+1. Ce qui permet, en passant par une fonction dédiée, de renforcer ensuite la partie "saisie" sans toucher au reste du code. Et tant qu'à faire (petite cerise), autant rendre la fonction un peu plus universelle en lui passant le prompt en paramètre.

Toutefois (petit bémol hélas), si la fonction renvoie le nombre saisi alors le lui faire aussi remplir devient peut-être un petit peu inutile non ?

Code C :

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
int inputNumber(char *prompt)
{
	int val;
	char line[20 + 1];		// + 1 pour bien montrer à mes collègues qui viendraient à reprendre ce code que je n'ai pas oublié l'espace pour le '\0'...
	while (1)
	{
		fputs(prompt, stdout);
		fgets(line, sizeof(line), stdin);
		if (sscanf(line, "%d", &val) == 1) break;			// Hoplà, un petit break qui mange pas de pain...
		printf("Votre saisie [%s] n'est pas valide - Recommencez\n", line);
	}
	return val;
}
...
 
while ((item=inputNumber("Entrez # pour add\n\tor 0 pour arrêter: ")) != 0)
{
	...
}

NB (qui à un rapport direct avec la toute première question): ceci fonctionne parce que le C est capable à la fois d'affecter une valeur et à la fois de l'évaluer. Dans un langage ne possédant pas cette propriété (même très récent comme par exemple Python), on serait obligé de
1) faire saisir, travailler et refaire saisir ensuite

Code c :

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

1
2
3
4
5
6
item=inputNumber("Entrez # pour add\n\tor 0 pour arrêter: ");
while (item != 0)
{
	...
	item=inputNumber("Entrez # pour add\n\tor 0 pour arrêter: ");
}

2) passer par un break

Code c :

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

1
2
3
4
5
6
while (1)
{
	item=inputNumber("Entrez # pour add\n\tor 0 pour arrêter: ");
	if (item == 0) break;
	...
}

Donc (@ p.salvador), quand tu demandes et regardes l'avis des gens, n'oublie pas que cet avis est bien entendu aussi influencé par cette possibilité qu'offre ce langage...

[Médinoc]

si la fonction renvoie le nombre saisi alors le lui faire aussi remplir devient peut-être un petit peu inutile non ?

En fait, j'aurais voulu que la fonction retourne *pItem != 0, mais vu qu'il n'y a pas de type Booléen en C90, je me suis dit que ce serait plus explicite si je retournais directement le nombre et mettait le test de nullité dans le if (et je n'ai pas pris le temps de changer le reste).

[Sve@r]

mais vu qu'il n'y a pas de type Booléen en C90

C'est pas grave. En C90 l'expression x != 0 renverra 0 si c'est faux et autre chose (presque certainement 1) si c'est vrai. Et ensuite tout if, tout while accepteront ce 0 ou ce 1 comme signifiant faux ou vrai.
Donc que tu fasses

Code c :

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

1
2
3
4
5
6
7
int saisie()
{
	...
	return x != 0;
}
...
if (saisie())

ou bien

Code c :

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

1
2
3
4
5
6
7
int saisie()
{
	...
	return x;
}
...
if (saisie() != 0)

Fonctionne exactement pareil. Sauf que le lecteur extérieur, lui, ne verra/comprendra pas la même chose...

[grim7reaper]

C'est pas grave. En C90 l'expression x != 0 renverra 0 si c'est faux et autre chose (presque certainement 1) si c'est vrai

Ce n’est pas presque certainement 1, c’est 1.
C’est défini dans le standard.

The == (equal to) and the != (not equal to) operators are analogous to the relational operators except for their lower precedence.

Et

Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.