Merci pour ta source, tous comme les autres je trouve le code un peu trop long pour ce qu'il doit faire mais il fait ce qu'il doit faire, demander une confirmation avant de quitter.
Le but quand on programme est que le code source soit lisible/compréhensible pas une autre personne afin que celle-ci soit en mesure de pouvoir modifier la source à sa guise.
Il est bien d'utilisé les if(var == true) car il sont facile à lire mais il ne faut pas abuser car à la longue ca alourdis le code (pas les performances mais la lisibilité).
c'est vrai qu'on peut reduire un peu ce code, il est un tantinet long.
les commentaires me semblent indispensables
et d'ailleurs ils ne sont pas vraiment normalisés,
il faut utiliser les tag <summary> et #region
pour faciliter le passage des outils de documentation
exp:
//-----------------------------------------------------------
/// <summary>
/// menu 'quitter'
/// </summary>
if( variable == true ) //si variable est vrai
{ //accolade ouvrante
variable = 0; //on met variable à zéro
} //accolade fermante, fin de si variable est vrai
écrire if(truc) n'est pas plus optimisé que d'écrire
if(truc==true)
on est dans le code source, le compilateur produit du code msil et c'est lui va être exécuté.
en l'occurence, pour les 2 écriture du if, le code généré est exactement le même (instruction brtrue ou brfalse) et c'est logique
parce que écrire if(truc) a forçement comme signification:
si truc est égal à vrai
au fond, il n'y a pas d'écriture plus ou moins bien, elles ont leur intérêt et leur point faible. les 2 sont tout a fait valables.
c'est mon expérience d'avoir trainé dans de nombreux sources (notamment du C et C++, le plus fatiguant) qui me fait préférer un style plus verbeux avec l'inconvénient de rallonger les codes sources, c'est sur.
en fait, quand je parle simplification... c'est surtout optimisation.
Le booléen est un type particulier, il se suffit généralement à lui-même.
Je ne vois pas l'intérêt de faire if (machin == true), puisque machin ne peut-être que true ou false.
J'ai plutôt l'habitude d'être "verbeux" dans le code et aussi dans les commentaires.
Ca fait longtemps que j'ai abandonné les pratiques style langage C, je préfére largement écrire if(truc==true/false) plutôt qu'utiliser les raccourcis trop concis -parfois utiles, c'est sûr- disponibles dans les langages.
c'est peut-être du à tous ces sources remplis à la va-vite de milliers de lignes de codes sans un brin de commentaires que j'ai du arpentés à la recherche de bugs ou qu'il fallait améliorer/réutiliser qui m'ont, eux, énervés.
Alors je préfére tout écrire -faire du clair-, c'est vrai que ca rallonge le code mais bon on ne paye pas la place dans un source et le but n'est pas de faire court mais de faire lisible et que ca marche et comme ca on peut tenir des milliers de lignes de codes.
C'est peut-être qu'aussi l'age avançant, mon cerveau a tendance à ramollir un peu à force de voir de tout et aussi de faire d'autres choses.
sinon, pour tempérer mon discours, la simplification
return MessageBox.Show(...) dans la méthode AskConfirmQuitAppli() est intéressante, je la retiens.
merci d'avoir commenté le code.
Pour quitter l'application:
protected override void OnClosing(CancelEventArgs e)
{
e.Cancel=(MessageBox.Show("Quitter?...","...",MessageBoxButtons.YesNo)==DialogResult.No);
if (!e.Cancel) Application.Exit();
}
OU
Pour quitter le formulaire:
protected override void OnClosing(CancelEventArgs e)
{
e.Cancel=(MessageBox.Show("Quitter?...","...",MessageBoxButtons.YesNo)==DialogResult.No);
if (!e.Cancel) this.Close();
}
if(MessageBox.Show("Quitter l'application?",
"Message de confirmation" ,
MessageBoxButtons.YesNo) == DialogResult.Yes)
{
Close();
}
???
protected override void OnClosing(CancelEventArgs e)
{
e.Cancel = !AskConfirmQuitAppli();
base.OnClosing (e);
}
Le but quand on programme est que le code source soit lisible/compréhensible pas une autre personne afin que celle-ci soit en mesure de pouvoir modifier la source à sa guise.
Il est bien d'utilisé les if(var == true) car il sont facile à lire mais il ne faut pas abuser car à la longue ca alourdis le code (pas les performances mais la lisibilité).
Ceci n'est pas une critique mais une opinion :)
Merci pour ta participation