si la fonction est grande avec de multiple return, tu as une bonne chance d’insérer du nouveau code après un return qui sera passé à cause d’une condition.
Euh, pour moi tu as autant sinon plus de chances d'avoir ce genre de problèmes avec du code qui a un single return.
Tu as aussi le problème du code qui réassigne les variables précédemment assignées.
OK, ça n'a rien a voir avec le problème dont on parle, juste que le style single return fait qu'il est plus facile de tomber dedans. Bon on peut toujours utiliser const/final pour éviter ça.
Pour moi c'est l'exemple typique pourquoi le single return est mauvais, parce qu'il permet d’écrire des horreurs pareille.
OK le compilateur sait éjecter ça, mais le programmeur doit a chaque fois payer la charge cognitive de comprendre ce code pour voir que non, le deuxième if ne fait rien (Le compilateur le fait aussi, mais il n'a pas mal a la tête lui).
Le code n'est pas mois maintenable ou debuggable. Le flot de contrôle est très facile a garder en entier dans sa tête.
Bref, a mon avis, le code après est bien plus maintenable que le code avant.
Je vous accorde que c'est peut être un cas dégénéré, mais que je rencontre très (trop) souvent lorsque les gens essayent de coller au maximum a la règle du single return.
[^] # Re: Rust vs Go
Posté par djano . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
Euh, pour moi tu as autant sinon plus de chances d'avoir ce genre de problèmes avec du code qui a un single return.
Tu as aussi le problème du code qui réassigne les variables précédemment assignées.
OK, ça n'a rien a voir avec le problème dont on parle, juste que le style single return fait qu'il est plus facile de tomber dedans. Bon on peut toujours utiliser const/final pour éviter ça.
Pour moi c'est l'exemple typique pourquoi le single return est mauvais, parce qu'il permet d’écrire des horreurs pareille.
OK le compilateur sait éjecter ça, mais le programmeur doit a chaque fois payer la charge cognitive de comprendre ce code pour voir que non, le deuxième if ne fait rien (Le compilateur le fait aussi, mais il n'a pas mal a la tête lui).
En fait, le single return promeut une écriture de code qui peut facilement devenir non lisible. Exemple réel que j'ai refactore hier et aujourd'hui:
* http://sources.forgerock.org/changelog/opendj?cs=11264 , regardez la methode equals() de ConnectionHandlersMonitoringTableModel.java
* http://sources.forgerock.org/changelog/opendj?cs=11261 , regardez la methode equals() de ServerDescriptor.java
Le code n'est pas mois maintenable ou debuggable. Le flot de contrôle est très facile a garder en entier dans sa tête.
Bref, a mon avis, le code après est bien plus maintenable que le code avant.
Je vous accorde que c'est peut être un cas dégénéré, mais que je rencontre très (trop) souvent lorsque les gens essayent de coller au maximum a la règle du single return.