Ben justement, je trouve que son explication, associée a celle d'un commentaire précédent présente l'inconvénient de la notation while(1){
....// code
}
Les deux cas qui montrent le côté bancal de cette notation sont les suivants d'après moi : for(int i = 0, monautrevar = -1; i < masupercondition; i++, monautrevar++) try
....// quelques
....// lignes
....// de
....// code
}
catch(...)
{
....MessageBox("plop");
}
ainsi que : while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....faisUn(truc) ;
....etEncore(un_autre) ;
....caVousAPlu(on_continue);
}
Dans ces deux exemples, on ne voit pas bien les débuts de blocs.
Dans le premier cas on croit que le début de bloc est for alors que c'est en fait try
Dans le deuxième cas, l'indentation ne permet pas de distinguer le début du bloc de la fin de la condition. Il faut regarder la première ligne qui ne commence pas par un opérateur pour pouvoir déterminer le début du bloc de code.
Et si en plus de cela on est dans ce cas : while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
On pourrait confondre, en lisant un peu rapidement, la première ligne de code du bloc avec la fin de la condition.
Une variante de cet exemple serait le cas suivant : unObjetAvecUnNomAssezLong.quiFaitQuelqueChose(avec,beaucoup,
....de, parametres);
if(monTest) {
....// du code
}
Personellement, quand je lis ce code en me disant 'Attention les accolades sont en fin de ligne', j'ai tendance à prendre la première instruction pour un début de bloc. Tandis que si je sais que le début d'un bloc sera clairement marqué par une accolade, je saurais directement que ce n'est qu'une ligne un peu longue qui est séparée en deux.
Après, je comprends que ce sont des cas qui ne justifient pas une occupation d'espace plus grande pour certains. Mais pour moi, ces cas reviennent assez souvent pour préférer l'autre notation, quitte à perdre un peu de place. Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif.
P.S.: désolé pour la mise en forme avec les points, les tabulations ne fonctionnaient pas chez moi...
[^] # Re: Saut de ligne avant l'accolade.
Posté par Joël SCHAAL . En réponse à la dépêche O.S.T.D.C. une introduction au Développement en équipe. Évalué à 2.
while(1){
....// code
}
Les deux cas qui montrent le côté bancal de cette notation sont les suivants d'après moi :
for(int i = 0, monautrevar = -1; i < masupercondition; i++, monautrevar++) try
....// quelques
....// lignes
....// de
....// code
}
catch(...)
{
....MessageBox("plop");
}
ainsi que :
while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....faisUn(truc) ;
....etEncore(un_autre) ;
....caVousAPlu(on_continue);
}
Dans ces deux exemples, on ne voit pas bien les débuts de blocs.
Dans le premier cas on croit que le début de bloc est for alors que c'est en fait try
Dans le deuxième cas, l'indentation ne permet pas de distinguer le début du bloc de la fin de la condition. Il faut regarder la première ligne qui ne commence pas par un opérateur pour pouvoir déterminer le début du bloc de code.
Et si en plus de cela on est dans ce cas :
while ((condition 1 && condition 2)
....|| condition 3 || (condition 4 && condition5
....&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
On pourrait confondre, en lisant un peu rapidement, la première ligne de code du bloc avec la fin de la condition.
Une variante de cet exemple serait le cas suivant :
unObjetAvecUnNomAssezLong.quiFaitQuelqueChose(avec,beaucoup,
....de, parametres);
if(monTest) {
....// du code
}
Personellement, quand je lis ce code en me disant 'Attention les accolades sont en fin de ligne', j'ai tendance à prendre la première instruction pour un début de bloc. Tandis que si je sais que le début d'un bloc sera clairement marqué par une accolade, je saurais directement que ce n'est qu'une ligne un peu longue qui est séparée en deux.
Après, je comprends que ce sont des cas qui ne justifient pas une occupation d'espace plus grande pour certains. Mais pour moi, ces cas reviennent assez souvent pour préférer l'autre notation, quitte à perdre un peu de place. Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif.
P.S.: désolé pour la mise en forme avec les points, les tabulations ne fonctionnaient pas chez moi...