Blog de dsr57 - Windev » normes;normes de programmation https://blog.developpez.com/dsr57 Blog sur l'edi windev Thu, 04 Jun 2015 11:46:25 +0000 fr-FR hourly 1 https://wordpress.org/?v=4.1.42 Windev : normes de programmation pour la POO https://blog.developpez.com/dsr57/p12189/windev/windev-normes-de-programmation-pour-la-poo https://blog.developpez.com/dsr57/p12189/windev/windev-normes-de-programmation-pour-la-poo#comments Thu, 22 Aug 2013 20:14:27 +0000 http://blog.developpez.com/dsr57/?p=117 Je continue la rédaction du blog en poursuivant sur les normes de programmation, je vais maintenant m’attaquer à la POO. Ce billet n’est pas une explication de la programmation objet en windev, elle explique la convention de nommage des différents éléments de la POO. dans un premier temps les normes pour le nom des classes, ensuite les membres et leurs propriétés, les méthodes et enfin un petit détail sur l’héritage.

Les classes

Windev ne gère pas explicitement les classes abstraites. Afin de bien différencier les classes abstraites et publiques, nous allons utiliser une convention de nommage sur le même principe :
    La portée : Première lettre (a : abstrait, p : public).
    le type : « c » comme classe suivi de « _ ».
    Le nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Exemple :

ac_document : classe abstraite
pc_article : classe publique
La déclaration d’un objet reprend la convention de nommage pour les variables de type simple, le type étant un objet, nous allons utiliser la lettre « o ».

Exemple :

lo_article est une pc_article

Les membres

les membres sont les données de l’objet. Celles-ci sont propres à l’objet, je les considère comme des variables locales, elles sont donc soumises à la convention de nommages des variables locales.

Exemple :

pc_article est une classe
   PRIVEE
       ls_refCommerciale est une chaine
       pm_montantHt est un monetaire
fin
Le niveau d’accès des membres est soit privé, soit protégé, et je définis les droits de lecture et écritures avec les propriétés. Une propriété doit avoir le même nom que sa variable sans la portée et le type. Pour l’exemple précédent on obtient :

PROCEDURE refCommerciale()
 renvoyer :ls_refCommerciale

PROCEDURE refCommerciale(ps_valeur est une chaine)

 :ls_refCommerciale=ps_valeur

Les méthodes

Les méthodes sont les opérations applicables aux objets. Pour celles ci je commence une méthode par « recup » si la méthode me permet de récupérer un objet et « recupListe » si la méthode permet de récupérer un tableau d’objet.

Héritage

L’héritage est un principe propre à la programmation orientée objet, permettant de créer une nouvelle classe à partir d’une classe existante. Le constructeur de la classe fille doit commencer par l’appel du constructeur de la classe principale. C’est à dire que le première ligne de code du constructeur de la classe fille doit faire un appel au constructeur de la classe de base. Ce réflexe vient de mon expérience en programmation Java, Java fait un appel automatique au constructeur de la classe héritée, sauf si celui-ci est appelé dans le constructeur. Windev n’effectue pas cet appel en automatique, il faut donc le forcer.

Exemple :

PROCEDURE Constructeur()
//-----Appel au constructeur par défaut
Ancêtre:Constructeur()
PROCEDURE Constructeur()
//----Appel à un constructeur
Ancêtre:Constructeur("Peugeot","308")
]]> 1 Windev : Norme de programmation pour les procédures et les champs graphiques https://blog.developpez.com/dsr57/p12170/windev/windev-norme-de-programmation-pour-les-procedures-et-les-champs-graphiques https://blog.developpez.com/dsr57/p12170/windev/windev-norme-de-programmation-pour-les-procedures-et-les-champs-graphiques#comments Thu, 08 Aug 2013 20:26:56 +0000 http://blog.developpez.com/dsr57/?p=56 Après un premier billet sur les normes de programmation pour les variables de type simple, je vais continuer dans le même registre en évoquant dans un premier temps les normes pour les procédures et ensuite les champs graphiques.

Les procédures (Et les fonctions ?)

Après maintes hésitations et des recherches sur le web, non pas pour connaître la différence entre une fonction et une procédure, mais la source et l’utilisation dans différents langages de ces 2 notions. Ces recherches ont résulté sur le faite que cette notion était indépendante de la conception algorithmique et dépendait du langage de programmation. Après une telle conclusion, je ne vais pas différencier le nom des fonctions et des procédures, tout sera procédure avec ou non une valeur de retour. Toujours en conservant le même principe de nommage
    La portée : Première lettre (G : Globale, l : locale).
    le type : « Proc » comme procédure suivi de « _ ».
    Le nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Exemple :

    Gproc_calculDateFinContrat : Procédure globale qui calcule la date de fin de contrat.
    lproc_calculMontantFacture : Procédure locale qui calcule le montant d'une facture.
    lproc_EstSolder : Fonction qui renvoie vrai ou faux selon si la facture est soldée.

Les champs graphiques

Ce paragraphe sera composé en première partie d’une liste des champs graphiques utilisés principalement dans les interfaces graphique, pour ensuite évoquer brièvement les groupes de champs et pour terminer je vais raconter une petite histoire qui m’a poussé à aller plus loin dans la convention pour les champs…

  • Pour la norme sur les noms des champs le principe varie un peu, un champ graphique est forcément local, il n’y a aucun intérêt à ajouter la portée au nom. Le nom sera composé de :

      • type : cf liste suivi de « _ ».
      nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

    Listes des champs :

      Fenêtre : Fen –> Fen_nomDelaFenêtre
      Fenêtre interne : FenI –> FenI_nomDelaFenêtre
      Fenêtre modèle : FenM –> FenM_nomDelaFenêtre
      Etat : Etat –> Etat_nomDeLEtat
      Etat interne : EtatI –> EtatI_nomDeLEtat
      Champ de saisie :Txt –> Txt_nomChamp
      Bouton : Btn –> Btn_nomChamp
      Image : Img –> Img_nomChamp
      Sélecteur : Opt –> Opt_nomChamp
      Interruptur : Chk –> Chk_nomChamp
      Combo, liste : Cbx –> Cbx_nomChamp
      Table : TAB –> TAB_nomChamp
      Jauge : Jau –> Jau_nomChamp
  • Windev permet de rassembler les champs en groupe, cela permet de consulter, modifier les caractéristiques des champs composant le groupe. Même principe que les champs graphiques, le groupe est local, on n’aura donc pas de notion de portée, le nom sera composé de
      Type : ‘grp’ suivi de « _ ».
      Nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

    Exemple :

      grp_boutons..visible=vrai

    Pour plus de renseignements sur les groupes voir la documentation sur le site de pc-soft : Documentation en ligne PC-Soft

  • Je vais maintenant évoquer un cas qui m’a demandé d’aller plus loin dans le nommage des champs. Dans ma carrière de développeur d’applications, j’ai créé énormément de fenêtres, dans lesquelles sont affichés différents champs. Je vais faire simple, j’ai dû programmer une fenêtre d’exportation selon un nombre de critères importants (Civilité, Secteur géographique, Profession, etc..)
      Chaque critère est composé de 3 champs :

    • Une zone texte « Code » : Saisir le code.
    • Une zone texte « Libellé » : Affiche le libelle du code
    • Un bouton « Recherche » : Affiche dans un tableau l’ensemble des possibilités du critère

      • .

      Au départ j’avais nommé mes champs

    • Code : txt_codeCritere
    • Libelle : Txt_LibelleCritere
    • Bouton recherche : Btn_RechCritere

    J’ai rencontré un petit souci quand j’ai commencé à coder la requête SQL. Je testais si le code du critère était renseigné, si oui je rajoutais une clause de sélection.

    Exemple de code :

    Si txt_CodeSecteur"" alors
         ls_requete+=" AND cli_secteur='"+txt_codesecteur+"'"
    fin

    Jusque là, vous ne voyez peut être pas de souçi, mon problème intervient avec la quantité de code. Quand on commence à taper le nom d’une variable, d’un champ ou autres objets Windev propose automatiquement une liste des champs qui commence par ce que l’on vient de saisir. Alors en commençant à saisir « Txt_code », je me retrouvais avec l’ensemble des critères de sélection, et donc une liste importante à parcourir. Alors qu’en inversant le nom du critère et le type d’information, on obtient :

    • Code : txt_Criterecode
    • Libelle : Txt_CritereLibelle
    • Bouton recherche : Btn_CritereRech
    Maintenant si je saisis « Txt_secteur », la liste affiche uniquement les champs Txt_secteurCode et Txt_secteurLibelle. La liste est diminuée, et donc plus confortable pour sélectionner le bon champs. je trouve que cette convention de nommage va plus loin dans l’organisation des champs et donne plus de souplesse lors de la codification.
]]> 1