Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 26
  1. #1
    Responsable Pascal, Delphi et Assembleur

    Avatar de Alcatîz
    Homme Profil pro Jean-Luc Gofflot
    Ressources humaines
    Inscrit en
    mars 2003
    Messages
    6 158
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Luc Gofflot
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ressources humaines
    Secteur : Service public

    Informations forums :
    Inscription : mars 2003
    Messages : 6 158
    Points : 40 797
    Points
    40 797

    Par défaut Bonnes pratiques de programmation en Pascal

    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.

    Règles du forum
    Tutoriels, exercices, FAQ, sources, compilateurs, outils, livres Pascal
    Mes tutoriels et sources Pascal
    FAQ Assembleur

    Le problème en ce bas monde est que les imbéciles sont sûrs d'eux et fiers comme des coqs de basse cour, alors que les gens intelligents sont emplis de doute. [Bertrand Russell]

  2. #2
    Responsable Pascal, Delphi et Assembleur

    Avatar de Alcatîz
    Homme Profil pro Jean-Luc Gofflot
    Ressources humaines
    Inscrit en
    mars 2003
    Messages
    6 158
    Détails du profil
    Informations personnelles :
    Nom : Homme Jean-Luc Gofflot
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ressources humaines
    Secteur : Service public

    Informations forums :
    Inscription : mars 2003
    Messages : 6 158
    Points : 40 797
    Points
    40 797

    Par défaut

    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é.
    Règles du forum
    Tutoriels, exercices, FAQ, sources, compilateurs, outils, livres Pascal
    Mes tutoriels et sources Pascal
    FAQ Assembleur

    Le problème en ce bas monde est que les imbéciles sont sûrs d'eux et fiers comme des coqs de basse cour, alors que les gens intelligents sont emplis de doute. [Bertrand Russell]

  3. #3
    Membre éprouvé
    Avatar de teubies
    Inscrit en
    octobre 2002
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : octobre 2002
    Messages : 129
    Points : 434
    Points
    434

    Par défaut

    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.

  4. #4
    Membre chevronné
    Avatar de EpiTouille
    Homme Profil pro Titouan Créac'h
    Étudiant
    Inscrit en
    mai 2009
    Messages
    333
    Détails du profil
    Informations personnelles :
    Nom : Homme Titouan Créac'h
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2009
    Messages : 333
    Points : 722
    Points
    722

    Par défaut

    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

  5. #5
    Membre chevronné
    Profil pro
    Développeur Java
    Inscrit en
    mars 2004
    Messages
    624
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mars 2004
    Messages : 624
    Points : 635
    Points
    635

    Par défaut

    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.

  6. #6
    Expert Confirmé Sénior
    Avatar de Paul TOTH
    Homme Profil pro Paul TOTH
    Freelance
    Inscrit en
    novembre 2002
    Messages
    5 561
    Détails du profil
    Informations personnelles :
    Nom : Homme Paul TOTH
    Âge : 45
    Localisation : Réunion

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 5 561
    Points : 15 875
    Points
    15 875

    Par défaut

    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;
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Produits : UPnP, RemoteOffice, FlashPascal
    Embarcadero : Ile de la Réunion, Dephi, C++Builder, RADPHP...TVA à 8,5%

  7. #7
    Membre Expert Avatar de popo
    Homme Profil pro Jérémy
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    806
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérémy
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 806
    Points : 1 048
    Points
    1 048

    Par défaut

    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 !

  8. #8
    Expert Confirmé Sénior
    Avatar de Paul TOTH
    Homme Profil pro Paul TOTH
    Freelance
    Inscrit en
    novembre 2002
    Messages
    5 561
    Détails du profil
    Informations personnelles :
    Nom : Homme Paul TOTH
    Âge : 45
    Localisation : Réunion

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 5 561
    Points : 15 875
    Points
    15 875

    Par défaut

    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.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Produits : UPnP, RemoteOffice, FlashPascal
    Embarcadero : Ile de la Réunion, Dephi, C++Builder, RADPHP...TVA à 8,5%

  9. #9
    Membre Expert Avatar de Dr.Who
    Inscrit en
    septembre 2009
    Messages
    980
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : septembre 2009
    Messages : 980
    Points : 1 299
    Points
    1 299

    Par défaut

    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;
    [ Sources et programmes de Dr.Who | FAQ Delphi | FAQ Pascal | Règlement | Contactez l'équipe ]
    Ma messagerie n'est pas la succursale du forum... merci!

  10. #10
    Rédacteur
    Avatar de darrylsite
    Inscrit en
    juillet 2007
    Messages
    1 300
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 1 300
    Points : 2 210
    Points
    2 210

    Par défaut

    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.

  11. #11
    Membre Expert Avatar de Dr.Who
    Inscrit en
    septembre 2009
    Messages
    980
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : septembre 2009
    Messages : 980
    Points : 1 299
    Points
    1 299

    Par défaut

    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
    [ Sources et programmes de Dr.Who | FAQ Delphi | FAQ Pascal | Règlement | Contactez l'équipe ]
    Ma messagerie n'est pas la succursale du forum... merci!

  12. #12
    Membre Expert Avatar de philnext
    Inscrit en
    octobre 2002
    Messages
    1 515
    Détails du profil
    Informations forums :
    Inscription : octobre 2002
    Messages : 1 515
    Points : 1 666
    Points
    1 666

    Par défaut Notation Hongroise

    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.

  13. #13
    Membre émérite
    Avatar de CapJack
    Homme Profil pro
    Prof, développeur amateur vaguement éclairé...
    Inscrit en
    mars 2004
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Prof, développeur amateur vaguement éclairé...
    Secteur : Enseignement

    Informations forums :
    Inscription : mars 2004
    Messages : 622
    Points : 970
    Points
    970

    Par défaut

    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;

  14. #14
    Membre chevronné
    Avatar de EpiTouille
    Homme Profil pro Titouan Créac'h
    Étudiant
    Inscrit en
    mai 2009
    Messages
    333
    Détails du profil
    Informations personnelles :
    Nom : Homme Titouan Créac'h
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2009
    Messages : 333
    Points : 722
    Points
    722

    Par défaut

    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;

  15. #15
    Expert Confirmé Sénior
    Inscrit en
    août 2006
    Messages
    3 561
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 3 561
    Points : 4 569
    Points
    4 569

    Par défaut

    Mau,

    Citation Envoyé par titeeee Voir le message
    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;
    [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
    Il court en ce moment une espèce de grippe, mais elle ne court pas très vite, car on peut l'attraper sans courir.

  16. #16
    Membre émérite
    Avatar de CapJack
    Homme Profil pro
    Prof, développeur amateur vaguement éclairé...
    Inscrit en
    mars 2004
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Prof, développeur amateur vaguement éclairé...
    Secteur : Enseignement

    Informations forums :
    Inscription : mars 2004
    Messages : 622
    Points : 970
    Points
    970

    Par défaut

    Citation Envoyé par droggo Voir le message
    Mau,
    Code :
    1
    2
    var
        nomFichier : string;
    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...

  17. #17
    Membre chevronné
    Avatar de EpiTouille
    Homme Profil pro Titouan Créac'h
    Étudiant
    Inscrit en
    mai 2009
    Messages
    333
    Détails du profil
    Informations personnelles :
    Nom : Homme Titouan Créac'h
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2009
    Messages : 333
    Points : 722
    Points
    722

    Par défaut

    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.

  18. #18
    Expert Confirmé Sénior
    Inscrit en
    août 2006
    Messages
    3 561
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 3 561
    Points : 4 569
    Points
    4 569

    Par défaut

    Qia,
    Citation Envoyé par CapJack Voir le message
    Grrr...

    Code :
    1
    2
    var
        FileName: string;
    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.
    Il court en ce moment une espèce de grippe, mais elle ne court pas très vite, car on peut l'attraper sans courir.

  19. #19
    Membre émérite
    Avatar de CapJack
    Homme Profil pro
    Prof, développeur amateur vaguement éclairé...
    Inscrit en
    mars 2004
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Prof, développeur amateur vaguement éclairé...
    Secteur : Enseignement

    Informations forums :
    Inscription : mars 2004
    Messages : 622
    Points : 970
    Points
    970

    Par défaut

    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.

  20. #20
    Rédacteur/Modérateur
    Avatar de M.Dlb
    Inscrit en
    avril 2002
    Messages
    2 340
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : avril 2002
    Messages : 2 340
    Points : 3 833
    Points
    3 833

    Par défaut

    Citation Envoyé par CapJack Voir le message
    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 !
    M.Dlb - Modérateur z/OS - Rédacteur et Modérateur Pascal

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •