Dans le premier exemple, le bloc est bien un bloc autour du « for », le « try » n'est qu'une surcouche.
Au niveau du sens on a qu'il y a une boucle, et qu'on teste les erreurs dans l'exécution des éléments de la boucle.
A mon avis on aurait pu mettre ça aussi :
for(i=0; i<10; i++) {
....try {
........malloc(1);
........fork();
....} catch {
........fprintf(stderr, "Je meurs !\n");
........exit(0);
....}
}
Ceci dit, lui il dit de la notation de son dernier exemple « Et enfin dans le genre très perturbant à mon avis », j'étais aussi d'accord avec cette phrase, j'aime pas cette façon d'écrire, c'est mieux comme j'ai fait plus haut !
Pour le deuxième exemple que tu proposes tu y as fait des choix douteux qui couplés avec l'accolade sur la ligne du « while » donne un résultat peu clair.
Ecrit plutôt comme ça, en alignant les éléments de la condition du « while » les uns avec les autres :
while ((condition 1 && condition 2)
..............|| condition 3 || (condition 4 && condition5
..............&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
De manière générale toute instruction simple qui doit s'écrire sur plusieurs lignes va être moins lisible que si elle était écrite sur une seule. Mais on n'a pas toujours le choix, surtout si on met des noms de variable à rallonge et qu'on reste quand même avec une limite à 80 colonnes pour la lisibilité.
Pour le troisième exemple par contre, je ne vois aucun problème de lisibilité, au pire on a l'impression qu'il y a deux blocs qui se suivent, mais jamais qu'il y a un bloc qui commence sur l'objet et termine sur l'accolade, pour la simple raison qu'il y aurait alors un élément non indenté en plein milieu et que c'est évidemment impossible si l'indentation est correctement faite. Et si elle ne l'est pas c'est normal que ça soit illisible, ou au moins ça n'est pas surprenant.
« Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif. »
Ouaip, les goûts de chacun. Je suis rapidement arrivé à la conclusion que ces différentes notations étaient une pure question de goût.
Ce qui me rebute dans le fait de scroller c'est que j'ai un effort à fournir pour pouvoir tout lire, si il n'y a pas besoin de scroller, la fenêtre d'édition est toujours bien centrée, il suffit de bouger les yeux, et quand tu passes d'une fenètre à une autre, il n'y a pas d'effort à faire pour savoir si on est au début ou à la fin de la fonction.
[^] # Re: Saut de ligne avant l'accolade.
Posté par Yth (Mastodon) . En réponse à la dépêche O.S.T.D.C. une introduction au Développement en équipe. Évalué à 3.
Au niveau du sens on a qu'il y a une boucle, et qu'on teste les erreurs dans l'exécution des éléments de la boucle.
A mon avis on aurait pu mettre ça aussi :
for(i=0; i<10; i++) {
....try {
........malloc(1);
........fork();
....} catch {
........fprintf(stderr, "Je meurs !\n");
........exit(0);
....}
}
Ceci dit, lui il dit de la notation de son dernier exemple « Et enfin dans le genre très perturbant à mon avis », j'étais aussi d'accord avec cette phrase, j'aime pas cette façon d'écrire, c'est mieux comme j'ai fait plus haut !
Pour le deuxième exemple que tu proposes tu y as fait des choix douteux qui couplés avec l'accolade sur la ligne du « while » donne un résultat peu clair.
Ecrit plutôt comme ça, en alignant les éléments de la condition du « while » les uns avec les autres :
while ((condition 1 && condition 2)
..............|| condition 3 || (condition 4 && condition5
..............&& condition 6 && condition 7)) {
....++i;
....faisUn(truc) ;
}
De manière générale toute instruction simple qui doit s'écrire sur plusieurs lignes va être moins lisible que si elle était écrite sur une seule. Mais on n'a pas toujours le choix, surtout si on met des noms de variable à rallonge et qu'on reste quand même avec une limite à 80 colonnes pour la lisibilité.
Pour le troisième exemple par contre, je ne vois aucun problème de lisibilité, au pire on a l'impression qu'il y a deux blocs qui se suivent, mais jamais qu'il y a un bloc qui commence sur l'objet et termine sur l'accolade, pour la simple raison qu'il y aurait alors un élément non indenté en plein milieu et que c'est évidemment impossible si l'indentation est correctement faite. Et si elle ne l'est pas c'est normal que ça soit illisible, ou au moins ça n'est pas surprenant.
« Et je trouve que scroller n'est pas aussi fatiguant que lire du code 'ramassé', mais ca, bien évidemment, c'est tout à fait subjectif. »
Ouaip, les goûts de chacun. Je suis rapidement arrivé à la conclusion que ces différentes notations étaient une pure question de goût.
Ce qui me rebute dans le fait de scroller c'est que j'ai un effort à fournir pour pouvoir tout lire, si il n'y a pas besoin de scroller, la fenêtre d'édition est toujours bien centrée, il suffit de bouger les yeux, et quand tu passes d'une fenètre à une autre, il n'y a pas d'effort à faire pour savoir si on est au début ou à la fin de la fonction.
Yth.