askToSave n'est pas encore mieux?
Sinon
void MainWindow::newListRequested()
{
if (tableIsModified==true && askToSave() && save())
{
/* Do whatever you want here */
}
}
C'est assez moche parce que ca depends du fait que si askToSave() retourne false, l'évaluation est stoppée la, mais bon c'est plus simple de travailler dans ce sens la non?
aka en décomposants:
if (tableIsModified)
{
if (proposeToSave())
{
save();
}
}
/* ou */
if (tableIsModified && proposeToSave())
{
save();
}
Zerosquare (./5) :
Perso je mettrais les return sur la même ligne que les if et je virerais les accolades pour que ça soit un peu moins verbeux, mais c'est plus une question de goût qu'autre chose.
De coller sur la meme ligne rends les choses moins compliquer a comprendre c'est sur, mais le C devrait absolument forcer l'utilisation des accolades, c'est un veritable nid a problème que de permettre l'utilisation sans les accolades
Il vaux meme mieux faire un
if (blah) { return; }que
if (blah) return;Mais c'est moins pire certes que le
if (blah)
return;qu'on trouve souvent..
mais je pense que ne pas mettre, meme exceptionnellement, les accolades est une erreur a long terme.
Les raison d'ecrire du compte "compact", en dehors des cas tres particulier ou tu as une serie de 200 if a la suite (que tu es obligé de faire) qui chacun ne prendre qu'une ligne de code, n'a de nos jour plus aucun sens, on est plus sur des machines avec 640Ko de mémoire et 360Ko de stockage en dur. On a plus besoin de chercher a reduire la taille du code pour que tout rentre sur un support de stockage, ni que la fonction tienne sur un ecran de 40x25 caracteres.
La majorité des raccourcis du C et d'autres languages viennent de la, et sont globalement des mauvaises habitudes. Un code "trop verbeux" ne va pas changer le code généré au final, il vaux mieux un code un peu trop verbeux mais bien ecrit qu'un code pas verbeux super compact qui en fait est pourrit au final.