Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Qu'en pensez-vous ?
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Qu'en pensez-vous ?
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Qu'en pensez-vous ?
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
"Yalbrieux" a écrit dans le message de
news:cgl9uk$dms$Pour une question de lisibilité, j'ai l'habitude d'écrire les
séquences switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
La lisibilité d'une indentation, sujet récurrent dans ce NG, reste
très subjective.
Ceci dit, dans le cas présent, pourquoi alourdir les "case" avec des
accolades alors qu'elles ne sont pas nécessaires ?
"Yalbrieux" <yalbrieux@wanadoo.fr> a écrit dans le message de
news:cgl9uk$dms$2@news-reader1.wanadoo.fr...
Pour une question de lisibilité, j'ai l'habitude d'écrire les
séquences switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
La lisibilité d'une indentation, sujet récurrent dans ce NG, reste
très subjective.
Ceci dit, dans le cas présent, pourquoi alourdir les "case" avec des
accolades alors qu'elles ne sont pas nécessaires ?
"Yalbrieux" a écrit dans le message de
news:cgl9uk$dms$Pour une question de lisibilité, j'ai l'habitude d'écrire les
séquences switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
La lisibilité d'une indentation, sujet récurrent dans ce NG, reste
très subjective.
Ceci dit, dans le cas présent, pourquoi alourdir les "case" avec des
accolades alors qu'elles ne sont pas nécessaires ?
Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
? Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
? Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
? Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Dans news:,Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus
de standards de programmation différents que moi) que même ceux
qui mettent des {} dans tous les if/else/while/for n'en mettent
pas systématiquement dans les case... Alors je ne dirais pas
c'est une « bonne pratique, et généralement acceptée ... ».
Dans news:wkd61dy3gu.fsf@fgeorges.org,
Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus
de standards de programmation différents que moi) que même ceux
qui mettent des {} dans tous les if/else/while/for n'en mettent
pas systématiquement dans les case... Alors je ne dirais pas
c'est une « bonne pratique, et généralement acceptée ... ».
Dans news:,Je pense que c'est une bonne pratique, et généralement
acceptée comme telle, d'utiliser systématiquement des blocs,
de manière à éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus
de standards de programmation différents que moi) que même ceux
qui mettent des {} dans tous les if/else/while/for n'en mettent
pas systématiquement dans les case... Alors je ne dirais pas
c'est une « bonne pratique, et généralement acceptée ... ».
Je sais pertinemment que je n'ai pas assez d'expérience de ce que
font les autres.
Je sais pertinemment que je n'ai pas assez d'expérience de ce que
font les autres.
Je sais pertinemment que je n'ai pas assez d'expérience de ce que
font les autres.
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Bonsoir,
Pour une question de lisibilité, j'ai l'habitude d'écrire les séquences
switch ainsi :
switch(..) {
case ... : {
... ;
break ;
}
...
}
(L'éditeur n'est évidemment pas d'accord avec cette indentation)
Dans news:,Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Je trouve les deux très difficiles à lire et pas très logique.
switch ( ... )
{
case ... :
{
MonType monObjet;
...
break;
}
case ... :
{
MonAutreType monObjet;
...;
break;
}
}
:-) (je répète : :-) )? Je pense que c'est une bonne pratique, et généralement acceptée
comme telle, d'utiliser systématiquement des blocs, de manière à
éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus de
standards de programmation différents que moi) que même ceux qui
mettent des {} dans tous les if/else/while/for n'en mettent pas
systématiquement dans les case... Alors je ne dirais pas c'est une
« bonne pratique, et généralement acceptée ... ».
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
Dans news:wkd61dy3gu.fsf@fgeorges.org,
Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Je trouve les deux très difficiles à lire et pas très logique.
switch ( ... )
{
case ... :
{
MonType monObjet;
...
break;
}
case ... :
{
MonAutreType monObjet;
...;
break;
}
}
:-) (je répète : :-) )
? Je pense que c'est une bonne pratique, et généralement acceptée
comme telle, d'utiliser systématiquement des blocs, de manière à
éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus de
standards de programmation différents que moi) que même ceux qui
mettent des {} dans tous les if/else/while/for n'en mettent pas
systématiquement dans les case... Alors je ne dirais pas c'est une
« bonne pratique, et généralement acceptée ... ».
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
Dans news:,Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Je trouve les deux très difficiles à lire et pas très logique.
switch ( ... )
{
case ... :
{
MonType monObjet;
...
break;
}
case ... :
{
MonAutreType monObjet;
...;
break;
}
}
:-) (je répète : :-) )? Je pense que c'est une bonne pratique, et généralement acceptée
comme telle, d'utiliser systématiquement des blocs, de manière à
éviter de mauvaises surprises.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
J'ai l'impression (et James pourra confirmer, car il a vu plus de
standards de programmation différents que moi) que même ceux qui
mettent des {} dans tous les if/else/while/for n'en mettent pas
systématiquement dans les case... Alors je ne dirais pas c'est une
« bonne pratique, et généralement acceptée ... ».
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
"Michel Michaud" wrote in message
news:<SnvXc.30377$...Dans news:,Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Que la légalité du premier dépend du type MyType.
Mais j'imagine que
c'était précisement pour ça que tu as présenté les deux.
Question d'habitude. En général, j'ai l'habitude de mettre le break en
dehors des {}. C-à-d comme si la syntaxe d'un cas était :
"case" <constante> ":" "{" statement_list "}" "break" ";"
Ou avec mon indentation habituelle :
case whatever :
{
code ;
}
break ;
L'idée de base, c'est que le break appartient au case, et non au code
régi par le case.
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura
donc jamais de break dans les {}.
Mais c'est une règle que j'effreinds assez souvent. La plupart des mes
case sont extrèmenent simple : ou bien une seule affectation, ou bien
l'appel d'une fonction.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
Seulement si MonType ou MonAutreTypeu a un constructeur non trivial.
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
Disons que ou bien, tu n'as qu'une ou deux instructions dans le switch,
ou bien, tu n'as qu'assez peu de case pour que le switch tient dans une
dizaine de lignes.
Mais je suis comme toi -- j'ai rarement des case
complexe, et malgré les règles, j'ai une tendance à les écrire sans les
{}, simplement parce qu'il ne contient qu'une seule instruction.
C'est ancien, et ça poserait des problèmes avec mon code actuel, mais je
me rappelle bien d'un compilateur qui appelait systèmatiquement le
destructeur pour tous les temporaires dans le bloc quand il quittait le
bloc. Y compris pour ceux qui était dans les cases non executés. Donc,
même quelque chose d'extrèmement simple pourrait poser des problèmes
s'il n'y avait pas les {}.
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<SnvXc.30377$DG.1410681@news20.bellglobal.com>...
Dans news:wkd61dy3gu.fsf@fgeorges.org,
Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Que la légalité du premier dépend du type MyType.
Mais j'imagine que
c'était précisement pour ça que tu as présenté les deux.
Question d'habitude. En général, j'ai l'habitude de mettre le break en
dehors des {}. C-à-d comme si la syntaxe d'un cas était :
"case" <constante> ":" "{" statement_list "}" "break" ";"
Ou avec mon indentation habituelle :
case whatever :
{
code ;
}
break ;
L'idée de base, c'est que le break appartient au case, et non au code
régi par le case.
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura
donc jamais de break dans les {}.
Mais c'est une règle que j'effreinds assez souvent. La plupart des mes
case sont extrèmenent simple : ou bien une seule affectation, ou bien
l'appel d'une fonction.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
Seulement si MonType ou MonAutreTypeu a un constructeur non trivial.
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
Disons que ou bien, tu n'as qu'une ou deux instructions dans le switch,
ou bien, tu n'as qu'assez peu de case pour que le switch tient dans une
dizaine de lignes.
Mais je suis comme toi -- j'ai rarement des case
complexe, et malgré les règles, j'ai une tendance à les écrire sans les
{}, simplement parce qu'il ne contient qu'une seule instruction.
C'est ancien, et ça poserait des problèmes avec mon code actuel, mais je
me rappelle bien d'un compilateur qui appelait systèmatiquement le
destructeur pour tous les temporaires dans le bloc quand il quittait le
bloc. Y compris pour ceux qui était dans les cases non executés. Donc,
même quelque chose d'extrèmement simple pourrait poser des problèmes
s'il n'y avait pas les {}.
"Michel Michaud" wrote in message
news:<SnvXc.30377$...Dans news:,Ceci dit, dans le cas présent, pourquoi alourdir les "case"
avec des accolades alors qu'elles ne sont pas nécessaires ?
Tout dépend de ce que représente « ... ». Que dire de :
switch ( ... ) {
case ... :
MyType my_object ;
... ;
break ;
case ... :
MyType my_object ;
... ;
break ;
}
comparé à :
switch ( ... ) {
case ... : {
MyType my_object ;
... ;
break ;
}
case ... : {
MyType my_object ;
... ;
break ;
}
}
Que la légalité du premier dépend du type MyType.
Mais j'imagine que
c'était précisement pour ça que tu as présenté les deux.
Question d'habitude. En général, j'ai l'habitude de mettre le break en
dehors des {}. C-à-d comme si la syntaxe d'un cas était :
"case" <constante> ":" "{" statement_list "}" "break" ";"
Ou avec mon indentation habituelle :
case whatever :
{
code ;
}
break ;
L'idée de base, c'est que le break appartient au case, et non au code
régi par le case.
Note aussi que j'utilise un style rigueureusement SESO ; il n'y aura
donc jamais de break dans les {}.
Mais c'est une règle que j'effreinds assez souvent. La plupart des mes
case sont extrèmenent simple : ou bien une seule affectation, ou bien
l'appel d'une fonction.
Si tu ne mets pas le bloc, dans ce cas-ci, tu auras une erreur.
Seulement si MonType ou MonAutreTypeu a un constructeur non trivial.
En fait, je pense que si tu as besoin d'une variable dans le bloc du
switch, il vaut mieux appeler une fonction. Je crois que mon switch
idéal a toujours une seule instruction par case, très semblable dans
tous les cas. Je sais, on ne peut pas toujours avoir l'idéal. :-(
Disons que ou bien, tu n'as qu'une ou deux instructions dans le switch,
ou bien, tu n'as qu'assez peu de case pour que le switch tient dans une
dizaine de lignes.
Mais je suis comme toi -- j'ai rarement des case
complexe, et malgré les règles, j'ai une tendance à les écrire sans les
{}, simplement parce qu'il ne contient qu'une seule instruction.
C'est ancien, et ça poserait des problèmes avec mon code actuel, mais je
me rappelle bien d'un compilateur qui appelait systèmatiquement le
destructeur pour tous les temporaires dans le bloc quand il quittait le
bloc. Y compris pour ceux qui était dans les cases non executés. Donc,
même quelque chose d'extrèmement simple pourrait poser des problèmes
s'il n'y avait pas les {}.
