Discussion :

[Papy214]

Bonjour,

Relisant de nombreuses lignes de code dans le cadre d'une migration de projet, je trouve souvent ce genre de code:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
procedure truc;
begin
if not freponse('blabla') then
begin
  ShowMessage('lalala');
  exit;
end;
...
end;

Je trouve ça lourd et je me dis qu'il y a peut-être une façon de faire autrement. Par exemple :

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
 
procedure test(t, m: string);
begin
 if not t then
 begin
  ShowMessage(m);
  ExitFonctionAppelante;   <<<---------
 end;
end;
 
procedure truc;
begin
  test(freponse('blabla'), 'lalala');  
end;
...
end;

Vous en pensez quoi ?

Bien sur, on mettre chaque test dans un try..except et déclencher une exception silencieuse mais je trouve ça encore plus "bof".

Papy !

[ShaiLeTroll]

Alors un Exit sur plusieurs niveaux n'existe pas, je ne crois pas non plus que le break puisse sortir de plusieurs boucles comme dans certains langages !?

Le problème, c'est qu'il me semble difficile de généraliser !
Personnellement mes fonctions ne contient JAMAIS de ShowMessage sauf si ce sont des méthodes d'un TForm !
J'ai une tendance à mettre le moins possible de code intelligent dans le TForm et a déporter la logique métier dans des objets métiers et plus ou moins dans des objets intermédiaires que l'on pourrait assimiler à des contrôleurs (MVC)

Je préfère un système de code d'erreur ou une exception (une vraie avec message et tout le tralala pas juste un abort)

personnellement je préfère écrire

Code :

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

1
2
3
4
5
6
7
8
9
 
procedure truc;
begin
if freponse('blabla') then
begin
  ... traitement
else
  ShowMessage('lalala');
end;

[Papy214]

J'utilise aussi ce système d' "exception" personnalisée mais j'ai lu par ici qu'il faut éviter de les utiliser à mauvais escient. Alors je me posais la question d'une autre solution.

Dans certaines unités du projet que je traite, il y a parfois 7 ou 8 cas traités par un "if..then exit" . Ca fait des procédures à rallonge.

Le exit(nomfonction) serait une bonne alternative. Dommage que ça n'existe pas.

[Papy214]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
procedure test01;
begin
  abort;
end;
 
procedure TForm7.Button6Click(Sender: TObject);
begin
  test01;
  ShowMessage(FormatDateTime('"Nous sommes le "dd-mm-yyyy', now));
end;

Ne déclenche pas le ShowMessage


ce qui revient à une exception silencieuse, j'en conviens

[Paul TOTH]

J'utilise aussi ce système d' "exception" personnalisée mais j'ai lu par ici qu'il faut éviter de les utiliser à mauvais escient. Alors je me posais la question d'une autre solution.

Dans certaines unités du projet que je traite, il y a parfois 7 ou 8 cas traités par un "if..then exit" . Ca fait des procédures à rallonge.

Le exit(nomfonction) serait une bonne alternative. Dommage que ça n'existe pas.

je ne comprend pas bien ton problème...

le mécanisme des exceptions est pratique pour sortir d'une sous-sous-sous procédure, mais ça complique la gestion des erreurs, on lui préfère donc Exit

ensuite rien ne t'empêche d'utiliser des sous-fonction

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
procedure truc;
begin
  if cond1 then 
  begin
    code1;
    exit;
  end;
  if cond2 then 
  begin
    code2;
    exit;
  end;
end;
 
// remplacé par
 
function code1: Boolean;
begin
  Result := cond1;
  if Result then
   ..
end;
 
function code2: Boolean;
begin
  Result := cond2;
  if Result then
   ..
end;
 
procedure truc;
begin
  if code1 or code 2 then
  Exit;
end;

[franckcl]

Me concernant, je n'utilise jamais "Exit" car je trouve qu'il rend la lecture du code plus compliqué.
C'est un peu comme les goto. En fait c'est un goto qui renvoie à la fin de la procedure, ni plus ni moins et ce n'est vraiment pas élégant.
Il y a d'autres solutions plus élegantes pour cela, comme utiliser un boolean par exemple. C'est souvent exploité pour traiter des erreurs retournées par des fonctions.
C'est sur qu'il faut taper plus de lignes mais c'est quand même plus élégant.

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
19
20
 
Function test(t, m: string) :boolean;
Var Err:boolean;
begin
  Err:=false;
  if not t then
  begin
    ShowMessage(m);
    Err:=true;
  end;
  result:=Err;
end;
 
Function truc:boolean;
Var Err: boolean;
begin
  result:=test(freponse('blabla'), 'lalala');  
end;
...
end;

[Rayek]

Je trouve ça aberrent de limiter l'utilisation de fonction de base parce que c'est pas "élégant"

Pour ma part j'utilise régulièrement des exit dans mes codes et il ne sont pas pour autant plus illisible qu'avec des if imbriqués.

Je préfère largement en lecture

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
19
 
function test : Boolean
begin
  Result := False;
 
  If Test1 Then
  begin
    Showmessage('Test1');
    Exit;
  end;
 
  If Test2 Then
  begin
    Showmessage('Test2');
    Exit;
  End;
 
  Result := True;
end;

Que ce code la

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
 
function test : Boolean
begin
  Result := True;
 
  If Test1 Then
  begin
    Showmessage('Test1');
    Result = False;
  end
  else If Test2 Then
  begin
    Showmessage('Test2');
    Result := False;
  End;
end;

[Papy214]

Paul:
Mon problème n'est pas dans la pertinence du code mais juste dans un souci de concision. Je trouve très souvent dans ce gros projet sur lequel je travaille des choses du genre:

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
if kekchose1 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose2 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose3 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose5 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose6 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose7 then
begin
  ShowMessage('blabla');
  exit;
end;
if kekchose8 then
begin
  ShowMessage('blabla');
  exit;
end;
 
....

Chaque test étant bati sur le même modèle. Bien sur que ça fonctionne, ainsi que le code que tu proposes. Mais j'ai des manies de vieux, j'aime faire des choses plus courtes et factorisées autant que faire se peut. De toutes manières, je ne changerai pas le code existant, ce n'est pas le but du travail demandé. Ce n'était qu'une question pour une utilisation future.

Au fait, y fait beau en ce moment dans les iles ?

[ShaiLeTroll]

Papy214, tu n'aurais pas quelques codes courts à nous fournir en exemple, des cas concrets, car sinon cela risque juste d'être un débat de formattage de code source qu'une réponse à ton problème !

En même temps, c'est si juste ça

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
19
20
21
22
23
24
25
26
27
28
29
30
if kekchose1 then
begin
  ShowMessage('blabla');
end
else if kekchose2 then
begin
  ShowMessage('blabla');
end
else if kekchose3 then
begin
  ShowMessage('blabla');
end
else if kekchose5 then
begin
  ShowMessage('blabla');
end
else if kekchose6 then
begin
  ShowMessage('blabla');
end
else if kekchose7 then
begin
  ShowMessage('blabla');
end
else if kekchose8 then
begin
  ShowMessage('blabla');
end;
 
....

Après, si tu as un retour, comme le fait remarquer Rayek, il ne faut pas être trop rigide, parfois une écriture convient mieux pour la lisibiliter, parfois une autre !

Sinon, si tes kekchoseN sont tous de la même forme (même paramètre) ou que tu peux faire en sorte qu'il soit tous pareils, cela peut se faire dans une boucle

Code :

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

1
2
3
4
5
6
for i := 1 to 8 then
begin
  p := MethodAddress(Format('kekchose%d', i));
  if Tkekchos(p)(param, message) then // param un objet, message une string en out
    ShowMessage(message);
end;

MethodAddress pouvant être remplacé par un tableau de fonction comme je l'avais fait là : Déclaration de pointeur de fonction et structure

En standardisant ton système (un controle de saisie je suppose, une validation des donnés ?) dans un objet utilitaire, tu pourras le réutiliser avec un minimum de code !
Juste après il faut déclarer les méthodes en published ou alors créer un Mapping sous forme de constante : Tableau Dynamique pointant sur Tableau Statiques

[Papy214]

En standardisant ton système (un controle de saisie je suppose, une validation des donnés ?) dans un objet utilitaire

C'est effectivement juste une question générale sur la l'écriture du code dans ce cas que l'on retrouve très souvent. Le projet en question contient environ 200 formulaires, chacun avec au moins une procédure contenant ce genre de code. Comme je dois passer dans toutes ces unités pour vérifier certaines choses, à force de voir tous ces tests bâtis sur le même principe, je me demandais si on n'aurait pas pu faire plus court.

C'est plus une question de style que de fonctionnalités :-)

[Gilbert Geyer]

Bonjour,

EXIT, c'est ma préférée, et je la mets toujours en Majuscules comme BREAK, et CONTINUE ... et pour la concision j' n'hésites pas à faire ceci :

Code :

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

1
2
3
4
5
6
function test : Boolean;
begin     Result := False;
          If Test1 Then begin Showmessage('Test1'); EXIT; end;
          If Test2 Then begin Showmessage('Test2'); EXIT; end; 
          Result := True;
end;

et ça ne nuit pas à la lisibilité... mais à chacun ses goûts.

A+.

[Papy214]

Je rajouterai pour Shai que ça va dans le même sens que ma question récente intitulée: "Type de classe en paramètre de fonction"

Dans le code, je vois régulièrement des

Code :

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

1
2
3
4
5
6
 
With TMYForm.Create(self) do
begin
  ShowModal;
  Release;
end;

Ma question avait pour but de réduire ça partout à une seule ligne par un simple appel à une fonction prenant en paramètre le type de la TForm à afficher. Ce qui permettait d'avoir une seule ligne de code à chaque fois plutôt que 5.

Maintenant, tout "factoriser" comme ça n'est pas forcément bon, je suis d'accord.

[Papy214]

Bonjour,

EXIT, c'est ma préférée, et je la mets toujours en Majuscules comme BREAK, et CONTINUE ... et pour la concision j' n'hésites pas à faire ceci :

et ça ne nuit pas à la lisibilité... mais à chacun ses goûts.

A+.

Là, c'est plus de la présentation de code. Perso, je suis pour une indentation à tous les étages, mais effectivement, chacun ses gouts.

Par contre, tu risques de lancer un débat passionné sur le sujet

[Rayek]

Je rajouterai pour Shai que ça va dans le même sens que ma question récente intitulée: "Type de classe en paramètre de fonction"

Dans le code, je vois régulièrement des

Code :

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

1
2
3
4
5
6
 
With TMYForm.Create(self) do
begin
  ShowModal;
  Release;
end;

Normalement pour être vraiment propre ton code devrait être un peu plus long

Code :

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

1
2
3
4
5
6
7
 
With TMYForm.Create(self) do
Try
  ShowModal;
finally
  Release;
end;

Ma question avait pour but de réduire ça partout à une seule ligne par un simple appel à une fonction prenant en paramètre le type de la TForm à afficher. Ce qui permettait d'avoir une seule ligne de code à chaque fois plutôt que 5.

Maintenant, tout "factoriser" comme ça n'est pas forcément bon, je suis d'accord.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
procedure TForm1.CreateAndShow(AFormClass : TFormClass);
var
  UneForm : TForm;
begin
  UneForm := AFormClass.Create(Self);
  Try
    Uneform.ShowModal;
  Finally
    UneForm.Release;
  End;
end;

[ShaiLeTroll]

Normalement pour être vraiment propre ton code devrait être un peu plus long

oui, dans ma réponse de Type de classe en paramètre de fonction, j'avais mis le try finally !

Rayek, tu sais pour un ShowModal, tu peux faire un Free sans risque, pas besoin d'un Release qui est utile si l'on libère dans un gestionnaire d'évènement !

Je rajouterai pour Shai que ça va dans le même sens que ma question récente intitulée: "Type de classe en paramètre de fonction"

Tiens, un sujet C++ Builder : Appel d'une fonction/TThread de façon paramétrique, c'est transposable en Delphi et ça te donne une idée des possibilités de généralisation !