effectivement c'est peut être plus verbeux mais tellement plus explicite : le nom de la méthode gestion_erreur indique déjà clairement ce qu'on fait : on traite une erreur; avec le goto je ne savais pas du tout ce qu'il y avait au bout du goto et ce qu'il faisait.
Après c'est vrai qu'en C y'a ce foutu problème d'absence d'unité d'encapsulation obligeant à mettre les variables en globales si on ne veut pas toutes les passer en paramètre. Une solution pour éviter la lourdeur serait de les encapsuler dans une structure.
par contre le "moins dupliqué" je ne suis pas d'accord", le "moins lisible" je dirais plutôt "moins verbeux". Mais si on part de ce principe on code en assembleur, c'est vrai quoi, au moins les instructions ne sont pas verbeuses et on peut mettre des jump partout !
Si tu le mets pas dans une autre fonction t'es obligé d'utiliser un goto de toutes façons.
???
Enfin comme quoi c'est possible de s'en passer de ces goto, c'est souvent plus verbeux mais on ne perd rien en duplication et pas grand chose en perfs.
[^] # Re: Hmm :/
Posté par TImaniac (site web personnel) . En réponse au journal Entretient du noyau Linux. Évalué à 2.
Après c'est vrai qu'en C y'a ce foutu problème d'absence d'unité d'encapsulation obligeant à mettre les variables en globales si on ne veut pas toutes les passer en paramètre. Une solution pour éviter la lourdeur serait de les encapsuler dans une structure.
par contre le "moins dupliqué" je ne suis pas d'accord", le "moins lisible" je dirais plutôt "moins verbeux". Mais si on part de ce principe on code en assembleur, c'est vrai quoi, au moins les instructions ne sont pas verbeuses et on peut mettre des jump partout !
Si tu le mets pas dans une autre fonction t'es obligé d'utiliser un goto de toutes façons.
???
Enfin comme quoi c'est possible de s'en passer de ces goto, c'est souvent plus verbeux mais on ne perd rien en duplication et pas grand chose en perfs.