Discussion :

[SergioMaster]

Bonjour,

considérez ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
function TRadioGroupBox.FindValue(const V: String): Integer;
var i : word;
begin
result:=-1;
if FrbValues.Count=0 then exit(-1);
for i:=0 to FrbValues.Count-1 do
 begin
   if FrbValues.Items[i]=V then
     begin
       FValue:=V;
       FIndexItem:=i;
       exit(i);
//       result:=i;
//       Break;
     end;
 end;
end;

est-il plus "propre" de sortir de la boucle for par le exit ou par le break (ce qui est commenté en dessous) ? Au final ça fait la même chose mais c'est juste pour me lever le doute
Merci

[free07]

Pour ma part et ce n'est qu'un avis perso, le plus propre est ce que nous avait dit un prof : " un seul point d'entré et un seul point de sortie ".

Je m'en suis souvenu lorsqu'un jour, on a eu le cas ou l'on a cherché un bug pendant des heures et des heures et ce bug était le résultat d'un cas particulier qui intervenait lors de l'exit ( ou du break ).
Depuis ce jour la, je n'ai jamais utilisé de break ou d'exit.

Mais bon, cela ne réponds pas du tout à ta question, je suis même mal placé pour y répondre, c'est juste un aparté que je me permets de faire

Il y a surement des cas ou il est difficile de faire autrement...

As tu vu la discussion suivante ? https://www.developpez.net/forums/d1...procedure-fin/

Confirmation avec docwiki, l'exit fait sortir de la procédure alors que le break sort uniquement de la boucle mais je suppose que tu sais déjà cela.

[ALWEBER]

Oui j'utilise exit très souvent . Par exemple si an objet n'est pas assigné ou est à nil. Ce qui peut être le cas sur des procédures événementielles.
Pour reprendre le dire du professeur - il a raison si nous somme dans une logique séquentielle. Or avec Delphi nous sommes essentiellement dans un traitement événementiel. D'autre part le "exit" permet souvent d'éviter l'imbrication des conditions.
Note : dans ton exemple je mettrai plutôt ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function TRadioGroupBox.FindValue(const V: String): Integer;
var i : word;
begin
result:=-1;
if FrbValues.Count=0 then exit ;
for i:=0 to FrbValues.Count-1 do
   if FrbValues.Items[i]=V then
     begin
       FValue:=V;
       FIndexItem:=i;
       result:=i;
       Break;
     end;
end;

donc dans une séquence sortir par break. Par souci de lisibilité préferer "result = i" à la place de "exit (i)"
note : un "begin end" en trop

[free07]

Pour reprendre le dire du professeur - il a raison si nous somme dans une logique séquentielle. Or avec Delphi nous sommes essentiellement dans un traitement événementiel. D'autre part le "exit" permet souvent d'éviter l'imbrication des conditions.

J'ai du mal à voir ce que vient faire le traitement événementiel car son propos incluait la portée, dans une fonction ou une procédure, le traitement est séquentiel. Ensuite tout est affaire d'analyse et justement l'exit du bug dont je parlais avais été mis pour éviter l'imbrication des conditions.

Mais je ne suis pas contre son utilisation, je pense qu'il faut vraiment l'utiliser lorsque l'on ne peut pas faire autrement et ce n'est qu'un avis perso !

[popo]

Tout comme ALWEBER j'utilise souvent le Exit dans la partie présentation pour sortir de la procédure si le contrôle des paramètres révèle une anomalie.
Dans la partie métier je préfère renvoyer une exception.

Je n'ai pas contre jamais utilisé le Exit avec un paramètre (à vrai dire j'ignorais cette possibilité).
Au niveau de la boucle, je suis d'avis que Exit n'est pas fait pour ça.

J'aurais donc le même code que ALWEBER à la différence que j'aurais laissé les begin-end.
Ne pas les mettre peut être sujet à des erreurs dans certains cas.
On a vite fait d'ajouter une ligne et d'oublier de les mettre.

[Andnotor]

Exit() est très pratique, il permet de "simuler" un goto :End qui évite nombre de tests et donc optimise le code.

Et question optimisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
function TRadioGroupBox.FindValue(const V: String): Integer;
begin
  result:=-1;
  if FrbValues.Count=0 then exit(-1);
 
  for i:=0 to FrbValues.Count-1 do
  begin
    if ... then Exit(i);
  end;
end;

je l'écrirais plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
function TRadioGroupBox.FindValue(const V: String): Integer;
begin
  for i:=0 to FrbValues.Count-1 do
  begin
    if ... then Exit(i);
  end;
 
  result:=-1;
end;

for..to teste déjà que l'étendue soit valide.
Result n'a plus besoin d'être initialisé en début de fonction depuis que l'Exit paramétré existe. C'est une ligne de moins à exécuter dans bon nombre de cas

[SergioMaster]

Je savais que ce code allait provoquer des interventions et merci pour ces réponses

il permet de "simuler" un goto :End qui évite nombre de tests et donc optimise le code.

Le fameux goto là c'est mes vieilles antiennes qui résonnent : "goto la mort des programmes" ... mais bon ces refrains étaient surtout pour le BASIC

for..to teste déjà que l'étendue soit valide.

Damned ! j'ai toujours eu un doute sur le for..to du coup j'ai raté ça !

[Charly910]

Bonjour,
à noter que dans l'IDE, les instructions Exit sont bien mise en valeur, ce qui facilite la maintenance de l'appli.

C'est vrai que l'utilisation de Exit était autrefois proscrite (tout comme les GoTo), mais maintenant, utilisé à bon escient je pense que cela simplifie et clarifie le code.

A+
Charly

[SergioMaster]

Bonjour,

Il est temps de clore le sujet par un
Je retourne me bagarrer avec la création de composants observables. Si le premier ne m'a posé aucun souci ma tentative de RadioGroupbox, dont l'extrait de code fait partie, me rend chèvre Ce qui fonctionne très bien hors package (création du composant au runtime) ne veut rien savoir en mode design

A ce propos, j'ai besoin de bêta-testeur mac et ios pour mon premier composant (mp avec votre adresse et je vous envoie mon zip)
En guise de remerciements les bêta-testeurs passeront à la postérité car ils seront cités dans le futur tutoriel : "LiveBindings de A à … Écrire un composant observable I"

[Andnotor]

C'est vrai que l'utilisation de Exit était autrefois proscrite

Par des puristes uniquement

[Galet]

Les conséquences de Exit ou Break sont, sur la lisibilité, beaucoup moins importantes que l'utilisation de Goto,, surtout en cas d'abus (Eh oui, c'est comme la bibine , merci Parcimonie).

Il me semble, cependant, que la question initiale était : Exit ou Break ?
J'avoue être, moi aussi, intéressé par les arguments des spécialistes ...

[Andnotor]

Les deux sont parfaitement identiques dans l'exemple de Sergio.

[Jipété]

Les deux sont parfaitement identiques dans l'exemple de Sergio.

Parce qu'il est minimaliste.

Il me semble, cependant, que la question initiale était : Exit ou Break ?
J'avoue être, moi aussi, intéressé par les arguments des spécialistes ...

Un Exit fait sortir de la fonction sans autre forme de procès.

Un Break fait sortir de la boucle et s'il y a des instructions ensuite (il n'y en a pas dans l'exemple de Sergio) elles seront exécutées. C'est là toute la différence.

[Andnotor]

Un Exit fait sortir de la fonction sans autre forme de procès.

C'est un peu plus compliqué que ça s'il y a des bloc finally. Et cela vaut pour les trois types de saut (Exit, Break mais aussi Continue).