Autant pour moi:
C'est dans le else, parce que je mets des return dans des if (même beaucoup )
C'est parce que je suis assez strict: Après on peut me le reprocher
Pour moi une fonction/ méthode doit avoir cette approche là:
XXXX toto (....) {// Postconditionif ( someCondition1 ) return YYY;// Even more postconditionsif ( someCondition2 ) return ZZZ;....if ( someConditionN ) return UUU;// All logic here.....// Final returnreturn VVV;}
Cela facilite la lecture, la maintenance (<- pincettes).
Avis personnel: il faut éviter d'avoir des return sauvages.
Ici, la fonction fait 3 lignes. Mais lorsque ta fonction/ méthode fait 25-30 lignes, il ne faut pas louper un return (surtout lors de la lecture du corps de la méthode/ fonction)
Sinon surprise
Niveau compilateur: peut être un rien en plus, mais je ne pense pas
Pour revenir à la fonction "fautive", c'est parce qu'elle ne fait pas grand chose. Donc elle reste lisible (et le débat peut être long )
Déjà on peut la modifier avec mon approche. Mais cela ne change rien.
Le plus gros changement, serait de mettre un return avec un test ternaire ((condition)? (true): (false));
En C, je ferai un #define parce qu'il n'y a pas d'allocations
De façon extrême ( ), compter son occurrence dans le code et en fonction du nombre soit
la supprimer
la hardcoder
trouver son équivalent. Parce que si je comprends bien le développeur a fait un "module" avec des fonctions plus ou moins officieuses qui lui manquait