Code Complete est un livre communément recommandé qui passe en détail sur ces types de problèmes stylistiques. Envisagez également de jeter un coup d'œil à certains des guides de style d'organisation publiés pour voir s'ils ont des opinions sur la question; Guide de style de Google , par exemple.
sur ce que je préfère, le deuxième exemple est beaucoup mieux à mon esprit. Le premier est essentiellement un abus du do {} tout en construisant pour éviter d'utiliser un goto, collant dogmatiquement à la lettre "Éviter les gotos à tout prix" tout en manquant son esprit de "Code de clarté, n'utilise pas de tours de langue inobvie" . P>
En fait, la seule raison d'utiliser un goto du tout serait de coller dogmatiquement à une approche «une seule déclaration de retour par fonction» lorsque vous pourriez vous éloigner avec un simple, lisible p>
if (!isAdmin()){
return false;
}
else if (!isConditionOne()){
return false; }
else if (!isConditionTwo()){
return false; }
else if (!isConditionThree()){
return false; }
else
return generateReport();
Plus vous avez des moyens de quitter une boucle / une fonction, plus un programmeur de maintenance qui doit la modifier dans quelques années le fera bu.
@Bill: C'est vrai si les déclarations de retour sont dispersées partout. Si vous avez des «clauses de garde» (comme dans la solution de Andy), les énoncés de retour représentant les conditions d'erreur sont tous recueillis et rendent le code restant très propre.