Bonnes pratiques de programmation en Pascal [Débat]

[Alcatîz]

Bonjour à toutes et à tous,

Le forum Pascal regorge de conseils et de bonnes pratiques de programmation. Force est de constater qu'il faut beaucoup de recherches pour les retrouver et que certains conseils doivent sans cesse être répétés aux développeurs qui débutent en Pascal.
D'où l'idée de les regrouper dans un unique fil de discussion.

Nous en profitons pour vous rappeler l'article de Philippe Gormand sur l'écriture de code Pascal, qui contient plein de conseils d'indentation et de mise en forme, de choix d'identificateurs, etc.

Nous vous invitons à partager avec tous les membres du forum vos meilleures pratiques. Lorsqu'il y aura suffisamment de matière, nous pourrons rassembler tous vos conseils dans un véritable guide.

[Alcatîz]

Quelques pratiques pour initier le débat :

• Pensez au couple papier+crayon !

Droggo n'a de cesse de le répéter (depuis le temps, il y a un copyright ) : avant de commencer à coder, couchez votre programme sur papier. Que ce soit en pseudo-code ou en langage courant, écrivez votre programme ou votre algorithme de manière claire et exécutez-le sur papier. Ce n'est qu'après cette étape de conception et de tests que vous pourrez traduire votre programme en Pascal.

• Indentez convenablement votre code

Une bonne indentation facilite la lecture et permet de détecter beaucoup d'erreurs, comme, par exemple, l'absence de fermeture d'un bloc d'instructions.

Qui peut facilement voir où manque un end dans ce code ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Program Chiffres_Lettres;
Uses WinCrt;
Var Caractere : Char;
Begin
InitWinCrt;
repeat
Write('Entrez un caractère ("X" pour quitter) : ');
Caractere := ReadKey;
WriteLn;
if Caractere in ['0'..'9'] then
WriteLn('C''est un chiffre.')
else if Caractere in ['A'..'Z','a'..'z'] then begin
Write('C''est une lettre ');
if Caractere in ['A'..'Z'] then
WriteLn('majuscule.') else WriteLn('minuscule.');
else WriteLn('C''est une lettre accentuée ou un caractère spécial.');
WriteLn;
until Caractere = 'X';
DoneWinCrt;
End.

...alors qu'on le voit tout de suite quand c'est indenté :

Code :

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
Program Chiffres_Lettres;
Uses WinCrt;
Var Caractere : Char;
Begin
  InitWinCrt;
  repeat
    Write('Entrez un caractère ("X" pour quitter) : ');
    Caractere := ReadKey;
    WriteLn;
    if Caractere in ['0'..'9']
       then
         WriteLn('C''est un chiffre.')
       else
         if Caractere in ['A'..'Z','a'..'z']
            then
              begin
                Write('C''est une lettre ');
                if Caractere in ['A'..'Z']
                    then
                     WriteLn('majuscule.')
                   else
                     WriteLn('minuscule.');
              end   (* <-- C'est ici ! *)
            else
              WriteLn('C''est une lettre accentuée ou un caractère spécial.');
    WriteLn;
  until Caractere = 'X';
  DoneWinCrt;
End.

• Soyez cohérent(e) dans votre approche

Essayez de traiter des problèmes identiques de manière similaire. Combien de fois voit-on qu'un bout de code a été écrit en utilisant un concept puis le bout de code suivant avec une autre approche, alors que la même approche aurait permis d'avoir un code cohérent.

• Commentez votre code !

Que ce soit pour vous relire vous-même plus tard ou pour qu'une autre personne lise et comprenne votre code, de grâce ajoutez suffisamment de commentaires là où c'est utile.

Par exemple, dans une procédure, indiquez l'utilité de vos variables locales. Si, dans un traitement, vous effectuez un tri, précédez le tri d'un commentaire du genre "Tri du tableau par quick-sort" : vous serez bien content(e), six mois plus tard, d'avoir ce commentaire pour vous rappeler immédiatement ce que fait votre code sans avoir à le relire pour le comprendre.

• Utilisez des identificateurs parlants

Il est très utile de choisir des noms d'identificateurs qui donnent un maximum de renseignements sur l'utilité d'une variable, un type, une procédure ou fonction, etc.

Par exemple, ce code :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Const AgeMajorite = 18;
 
Type TTabEntiers = Array [1..20] of Integer;
 
Var TableauAges : TTabEntiers;
 
Function Age_Maximum (Const Tableau : TTabEntiers) : Integer;
Begin
  (* ... *)
End;
 
Begin
  (* ... *)
  if Age_Maximum(TableauAges) > AgeMajorite
     then
  (* ... *)
End.

est beaucoup plus parlant que :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Type t = Array [1..20] of Integer;
 
Var a : t;
 
Function v (const tab : t) : Integer;
Begin
  (* ... *)
End;
 
Begin
  (* ... *)
  if v(a) > 18
     then
  (* ... *)
End.

• Structurez vos programmes

Le Pascal permet énormément de souplesse pour structurer son code. Isolez chaque traitement dans une procédure ou fonction et découpez vos programmes en unités. La structuration logique d'un programme facilite grandement sa compréhension, sa lecture et sa maintenance. De plus, vous pourrez plus aisément aisément réutiliser votre code dans d'autres programmes.

• Une procédure ou fonction est une boîte hermétique

Une procédure ou fonction doit recevoir comme paramètres tout ce dont elle a besoin et ne doit pas travailler directement avec des variables globales. Il faut considérer la procédure ou fonction comme une boîte hermétiquement fermée, qui reçoit d'un côté des paramètres et qui renvoie de l'autre côté un résultat et/ou une version modifiée des paramètres reçus en entrée.

En appliquant systématiquement cette règle, on facilite la compréhension et le débogage d'un programme.

• Transmettez vos paramètres invariables comme constantes

Quand c'est possible (ce qui n'est pas le cas en Turbo Pascal), transmettez à vos procédures et fonctions des paramètres qui ne doivent pas être modifiés comme constantes. Si vous les transmettez par valeur, il sont inutilement recopiés sur la pile, ce qui est un non-sens en matière d'optimisation.

Si l'on reprend un exemple cité plus haut :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Const AgeMajorite = 18;
 
Type TTabEntiers = Array [1..20] of Integer;
 
Var TableauAges : TTabEntiers;
 
Function Age_Maximum (Const Tableau : TTabEntiers) : Integer;
Begin
  (* ... *)
End;
 
Begin
  (* ... *)
  if Age_Maximum(TableauAges) > AgeMajorite
     then
  (* ... *)
End.

La fonction Age_Maximum ne modifie pas le tableau TableauAges, elle ne fait qu'en extraire la valeur maximum. Il est donc logique de passer le tableau comme constante et seule son adresse est déposée sur la pile. Tandis que si on l'avait passé par valeur :

Code :

Function Age_Maximum (Tableau : TTabEntiers) : Integer;

il serait intégralement recopié sur la pile, ce qui prendrait inutilement du temps machine et consommerait inutilement de l'espace sur la pile.

• Utilisez des constantes pour représenter des valeurs numériques

En déclarant des constantes pour représenter des valeurs numériques utilisées dans un programme, on se facilite la vie : il suffit de modifier la déclaration d'une constante en tête de programme ou d'unité pour que cela modifie automatiquement tous les exemplaires de sa valeur dans le programme ou l'unité.

[teubies]

Mettre un préfixe à ses variables en fonction du contexte
-Paramètre A + nom de la variable
-Variable local L + nom de la variable
-Champs d'une classe F + nom de variable

Lors de la création d'un objet pensez toujours à mettre (quand c'est possible) sa destruction dans un finally.

Code :

1
2
3
4
5
6
  LData := TMemoryStream.Create;
  try
  // traitement
  finally
    LData.Free;
  end;

Essayer de respecter fonction qui créer un objet = fonction qui détruit cet objet

Je suis pour ma part totalement contre le with qui empêche l'inspection correct des variables en delphi et qui est source de bug.

[EpiTouille]

Pensez à utilisé plusieurs fichiers pour de long code. Surtout avec Tp.
C'est plus facile de changer de fenetre avec F6 que de parcourir 70 fonctions ou procedures .

J'ai déja vu des codes avec 150 fonctions dans le main. C'est pas humain
Ce que je fais c'est que je donne le 'U' a mon préfix d'unit, comme ça je sais directement ou est le main. comme par exemble Uoption ou Usauvegarde.

Pour moi, le plus important a part l'indentation est le fait de mettre de nom explicite a vos variables. Comme j'ai aussi lut dans 'Code Proprement', les commentaire c'est bien mais il ne faut pas trop en mettre sinon, ça alourdie vachement le code. Certaines fois, une procedure avec de nom claire, et un bon code peut éviter une panoplie de commentaires mais les commentaires sont utiles aussi;

Aussi éviter les GOTO et les Break. Il y d'autre moyen plus lisible de s'y prendre.

Titeeee

[bubulemaster]

Bonjour,

pour ma part, contrairement à l'article de Philippe Gormand sur l'écriture de code Pascal.
Je suis pour toujours mettre begin end. Comme ça si on rajoute dans un block on est sûr que c'est pris et on est sûr où s'arrête le block

Totalement contre le "with" comme teubies, car c'est illisible.

La "ligne de séparation" à voir, c'est utile pour l'entête de fonction et encore. Ca alourdi la lecture du code je trouve.

Pour l'utilisation du break voir au cas par cas, dès fois ça simplifie les choses et évite de mettre des conditions à rallonge.

[Paul TOTH]

j'ai changé 5 ou 6 fois de choix de mise en forme de mes sources au cours de ma longue carrière

il faut savoir qu'un source est d'autant plus lisible qu'il est sous la forme à laquelle on est habitué.

par exemple, le begin en fin de ligne ou à la ligne va être pratique ou pas selon l'habitude

Code :

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
 
 if test then begin
   ... 
 end;
// si on s'attend à avoir le begin sous le if, 
// on se demande ce que fait ce end ici
 
 
 if test then 
 begin
   ... 
 end;
// si on a l'habitude d'avoir le begin en fin de ligne, 
// le if semble inachevé car il n'a pas de end correspondant
 if test then begin
  ...
 end;
 begin
   ... 
 end;
// on pire, il semble indépendant du begin/end
 if test then Inc(x);
 begin
   ... 
 end;

J'ai longtemps privilégié l'écriture compacte, car elle permet d'avoir un maximum d'informations dans un minimum de place

Code :

1
2
3
4
5
 
  // tester les bornes
  if (x<0)or(y<0) then continue;
  if x>maxx then begin x:=0; Inc(y); end;
  if y>maxy then exit;

aujourd'hui je préfère un code aéré bien qu'il occupe plus d'espace

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
  // point avant l'image
  if (x < 0) or (y < 0) then 
    Continue;
 
  // changement de ligne
  if x > MaxX then 
  begin 
    x := 0; 
    Inc(y); 
  end;
 
  // au delà de l'image on s'arrête
  if y > MaxY then
   Exit;

Mais tout cela est sans doute moins important avec l'apparition des outils de refactoring.

pour ce qui est de l'usage de With, c'est un outil comme un autre
je l'utilise notamment avec les Canvas, ça permet en modifiant une ligne de changer les choses sans passer par une variable temporaire

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
{$IFDEF DIRECT_PAINT}
 with Canvas do
{$ENDIF}
{$IFDEF BITMAP_PAINT}
 with FBitmap.Canvas do
{$ENDIF}
{$IFDEF PAINTBOX_PAINT}
 with TPaintBox(Sender).Canvas do
{$ENDIF}
 begin
  ...
 end;

[popo]

Pour ma part, je vais reprendre l'un des éléments de Alcatiz (le passage de paramètres) et développer un peu plus car, c'est selon moi un point essentiel à l'optimisation

A l'exception des varaibles objet
- Tout paramètre dont la valeur en utilisée seulement en entrée et qui n'est pas modifiée en sortie doit être passée en const
- Tout paramètre dont la valeur est systématiquement modifiée et dont la valeur initiale n'est pas utilisée doit être passée en out
- Tout paramètre dont la valeur est utilisée en entrée comme en sortie doit être passé en var

On peut rapidement voir la différence par exemple lors du passage de paramètre de type chaine et en particulier les WideString



Un autre point que je trouve particulièrement important, c'est d'éviter d'utiliser les composant dans une procédure de traitement qui ne nécessite pas leur utilisation.
Exemple concret à ne pas faire :

Code :

1
2
3
4
5
function EstDateSuperieurADateDuJour : Boolean;
begin
  Result := False;
  if (MonDateTimePicker.Date > now) then Result := True;
end;

Préférer ceci :

Code :

1
2
3
4
5
function EstDateSuperieurADateDuJour(Const UneDate : TDateTime) : Boolean;
begin
  Result := False;
  if (UneDate > now) then Result := True;
end;

Cela évite de refaire une fonction si la date d'un autre composant doit être validée. Malheurement, on voit encore se genre de chose dans le monde professionnel !

[Paul TOTH]

autre bonne pratique, et c'est valable dans tous les langages, ne pas faire une fonction de 15 pages de long, c'est imbuvable. Et sur 15 pages on peut forcément identifier des sous-traitements à mettre dans des sous-fonctions afin de rendre le tout plus digeste.

dans le même genre, il faut bannir le copier/coller de code (celui-là même qui produit des fonctions de 15 pages), si un code est suffisamment proche d'un autre pour permettre un copier/coller, c'est que le code peut être paramétré dans une sous-fonction qui sera utilisée deux fois.

[Dr.Who]

Evitez les dépendances aux variables globale de classe dans l’implémentation de cette classe (FormX):

NE PAS FAIRE :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
var 
  Form1 : TForm1;
 
implementation
 
procedure TForm1.button1Click(Sender: TButton);
begin
  Form1.caption := 'Bonjour';
  // dépendance à la variable : Form1 -> source de bugs
end;

FAIRE :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
var 
  Form1 : TForm1;
 
implementation
 
procedure TForm1.button1Click(Sender: TButton);
begin
  Caption := 'Bonjour';
  // ou Self.Caption (temporairement en test, inutile en prod)
end;

[darrylsite]

j' ajouterai qu'il faut éviter de mélanger de la POO et du procédurale surtout dans une même unité (fichier). Le cas le plus courant se retrouve dans les forms.

[Dr.Who]

Structurer les fichiers sources :



- Nommer l'unité principale "Main" par exemple ou "TotoMain" pour votre projet "Toto".

- Les fonctions d'outils peuvent être délocalisée dans une unité "Tools" ou "Utils" ou encore "TotoUtils", "TotoTools"

- Chaque unité doit être nommée selon son utilisation, Outils (Tools, Utils), Traduction (Lang, Language), Importation/Exportation (Import, Export), gestion des données (BinFiles, DatFiles, ZipFiles, DbFiles) etc. Soyez clair, précis et concis.

- Placez les ressources dans un sous-dossiers "Ressources" ou "Res" ou encore "Medias", hiérarchisez correctement vos projets en séparant chaques types de données (sons, images, scripts etc), exemple de structure claire :

• \Toto
  • \Garbage
  • \Medias
    • \Sounds
    • \Sounds\open.ogg
    • \Sounds\close.ogg
    • \Sounds\click.ogg
    • \Graphics
    • \Graphics\logo.jpg
    • \Graphics\ground.jpg
    • \Graphics\splash.jpg
    • \Datas
    • \Datas\DataBase.db
  • \Setup
    • \Licence
    • \Licence\CeCill.fr.txt
    • \Licence\CeCill.en.txt
    • \Script
    • \Script\Toto.iss
    • \Script\Toto.ico
    • \Release
    • \Release\Toto-setup-v1.0.0.0.exe
    • \Release\Toto-setup-v1.0.1.0.exe
    • \Release\Toto-setup-v1.0.2.0.exe
  • \Setup\ChangeLog.txt
• \Toto\Toto.dproj
• \Toto\Toto.res
• \Toto\Toto.dfm
• \Toto\TotoMain.pas
• \Toto\TotoTools.pas

[philnext]

Pour rajouter sur ce qui a déjà été dit je trouve intéressant d'utiliser la notation hongroise http://fr.wikipedia.org/wiki/Notation_hongroise ça permet de visualiser immédiatement le type de variable, surtout quand on travaille à plusieurs sur les même sources.

[CapJack]

Se contraindre à choisir des identificateurs en anglais, car c'est la langue véhiculaire du développement.

Pour les compilateurs qui le permettent (Delphi...), en programmation objet, ne pas hésiter à consolider le code en pratiquant un usage réfléchi des directives private, protected, public.

Éviter d'accéder directement aux champs des objets (qui seront mis en private).

Se contraindre (je sais, c'est parfois pénible) à privilégier l'utilisation des propriétés en déclarant celles qui n'ont pas à être modifiées en lecture seule.

Ceci:

Code :

1
2
3
4
5
6
7
8
9
10
type
  TThink = class
  private
    FIdent : Integer;
  protected
    procedure DefinedInDescendant; virtual; abstract;
  public
    constructor Create(AnIdent: Integer);
    property Ident: Integer read FIdent;
  end;

est plus robuste que cela :

Code :

1
2
3
4
5
6
type
  TThink = class
    Ident : Integer;
    procedure DefinedInDescendant; virtual; abstract;
    constructor Create(AnIdent: Integer);
  end;

[EpiTouille]

J'aime bien mettre le begin sur la ligne des procedures exemple :

Code :

1
2
3
4
procedure UnTruc(a : param); begin
  Instruction;
  Instruction;
end;

Comme ça c'est cohérent avec les boucles

Code :

1
2
3
4
5
if Boolean then begin
  Instructions;
  ...
  ...
end;

c'est plus facile.

Sauf quand y'a des beaucoup de variables; mais sinon, j'essai de les mettre en ligne aussi;

Code :

1
2
3
4
procedure UnTruc(a : param);var untruc : boolean; begin
  Instruction;
  Instruction;
end;

[droggo]

Mau,

Envoyé par titeeee

J'aime bien mettre le begin sur la ligne des procedures exemple :

Code :

Comme ça c'est cohérent avec les boucles

Code :

[TROLL]

Quelle boucle ?

[/TROLL]

D'autant plus que rien ne t'oblige à écrire tes if ... then begin sur la même ligne.

Personnellement, je préfère quelque chose comme

Code :

1
2
3
4
5
6
7
8
9
10
11
if ....
then
  begin
    instruction
    ...
  end
else
  begin
    instruction
    ...
  end;

ce qui a le mérite de garder une même indentation pour les mots clés associés (if then else d'une part, begin end de l'autre...), et facilite la délimitation visuelle des blocs.

Mais bien sûr, tout cela définit des préférences personnelles.

Et il y a bien entendu les noms à définir proprement, qui doivent être explicites et écrits clairement

Code :

1
2
var
    nomFichier : string;

est plus lisible que

Code :

1
2
var
    nomfichier : string;

et bien plus agréable à lire que

Code :

1
2
var
    s : string; {nom du fichier}

ce qui amène à mettre un commentaire, avec perte de l'information sur chaque usage de la variable (ou constante, fonction ...), particulièrement quand on a pas mal de variables dans une procédure.

etc.

Bref, un gros effort sur la présentation, lisibilité du code.

C'est un peu contraignant au début, mais avec l'habitude, ça devient automatique, et fait gagner beaucoup de temps quand on reprend un code après des mois (et même des années, ça m'est arrivé), et plus encore quand quelqu'un d'autre doit reprendre le code

[CapJack]

Envoyé par droggo

Mau,

Code :

Grrr...

Code :

1
2
var
    FileName: string;

Plus généralement, on a tous nos petites habitudes, ça fait aussi partie de la liberté tant que le code est lisible et compréhensible. Et pour ça, trois règles : indenté, léger, commenté. Après, 'faut pas tomber dans l'intégrisme. J'écris ça de façon générale, hein, ça n'est adressé à personne en particulier, bien évidemment...

[EpiTouille]

Pardon, j'avais penser au début à mettre une boucle for

Code :

1
2
3
4
5
for i := 1 to 10 do begin
  instruction;
  ...
  ...
end;

Je prefère cette notation car on a bien le for et le end indenté pareil. On voit donc bien les limites de la boucle. Et donc, même principe pour les procedures

alors que

Code :

1
2
3
4
5
6
for i := 1 to 10 do
 begin
   instruction;
   ...
   ...
 end;

on a un espace vide entre le end et a marge. Je trouve qu'on ne voit pas forcement au premier coup d'oeil, ce que délimitent les begin/end.

Après c'est un choix personnel.

[droggo]

Qia,

Envoyé par CapJack

Grrr...

Code :

Désolé, mais je ne vois aucune raison convaincante d'utiliser des mots anglais pour définir les noms.

Si mes programmes doivent être repris par quelqu'un d'autre, il faudra forcément qu'il/elle comprenne assez bien le français, car toutes les applications que je développe sont sont des commandes faites par des sociétés/associations... françaises (en sus des applis perso, bien entendu), et ceux/celles qui auront malgré tout l'occasion de les lire - en principe, personne - n'auront qu'à faire l'effort, il n'y a pas de raison que ce soit toujours dans le même sens (je te vois venir : "l'anglais est la langue internationale, ...", mais pffft ).

Pour le reste, il est clair que les préférences personnelles interviennent fortement, et que notre œil s'habitue à ... nos habitudes.

[CapJack]

Eh bien, en plus du fait que l'anglais soit effectivement international (), il y a aussi une autre raison, esthétique celle-là. Si seulement les mots-clés pouvaient être localisés... mais ce n'est pas le cas, alors :

Code :

  if IsDefined(PointsArray) then...

est agréable, tandis que

Code :

if EstDefini(TableauPoints) then...

m'a toujours fait bondir au plafond. C'est quoi, ce franglais ? 'Pi, pas d'accents en plus ! Je sais, Delphi permet les accents depuis un certain temps, mais ce n'a pas été toujours le cas.
Enfin voilà, c'est aussi purement esthétique. J'dois être artiss', quèqu'part.

[M.Dlb]

Envoyé par CapJack

Eh bien, en plus du fait que l'anglais soit effectivement international (), il y a aussi une autre raison, esthétique celle-là. Si seulement les mots-clés pouvaient être localisés... mais ce n'est pas le cas, alors :

Code :

  if IsDefined(PointsArray) then...

est agréable, tandis que

Code :

if EstDefini(TableauPoints) then...

m'a toujours fait bondir au plafond. C'est quoi, ce franglais ? 'Pi, pas d'accents en plus ! Je sais, Delphi permet les accents depuis un certain temps, mais ce n'a pas été toujours le cas.
Enfin voilà, c'est aussi purement esthétique. J'dois être artiss', quèqu'part.

Même si ca doit en faire bondir plus d'un, je soutiens Capjack sur ce point... Tous les noms des procédures, fonctions incluses dans Pascal (et plus généralement dans quasiment tous les langages de programmation) sont en anglais, et mélanger français et anglais c'est juste moche !