Dans une suite de billets j’avais présenté une norme de nommage des différents éléments WinDev que je préconise et met en place lors de mes différentes programmations. Avec ce billet, je propose une amélioration sur le nom des procédures visant à améliorer la compréhension des traitements effectués par la celles-ci en lisant leur nom, pour cela j’ai mis en place un nouvelle partie dans le nom visant à isoler l’action de la procédure.Dans un premier temps nous allons voir la mise en place de cette amélioration pour les procédures globales, ensuite les procédures locales et pour terminer les procédures (généralement appelées méthodes) de classe.

Liste des billets sur les normes de programmation en WinDev :
• WinDev : normes de programmation pour les variables de type simple
• Windev : normes de programmation pour les procédures et les champs graphiques
• WinDev : normes de programmation pour la POO

Global au projet (Collections de procédures)

Les procédures déclarées dans une collection de procédures ont une portée globale au projet. Le nom sera composé de 3 parties :
• préfixe : obligatoire et fixe «GProc ». « G » pour globale au projet, « Proc » pour procédure ;
• action : obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions ci-dessous.
• nom : obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en majuscule.

Les trois parties seront séparées par le caractère « _ ».

Exemple :

Liste des actions :
• Afc : Affichage ;
• Ajt : Ajout ;
• Clc : Clic sur un bouton ;
• Ent : Entrée dans un champ ;
• Ini : Initialisation ;
• Lst: Récupération d’une liste de valeur ou une liste d’objet ;
• Raz : remise à zéro ;
• Rch : Recherche ;
• Rcp : Récupération d’une valeur ou d’un objet ;
• Sel : Sélection (ligne de table, combo) ;
• Sor : Sortie d’un champ ;
• Spr : Supprime/suppression ;
• Vrf : Vérification.

Cette liste est non exhaustive, elle doit être complétée/améliorée/modifiée selon les besoins de chacun. J’ai volontairement oublié l’action EXE, pour éviter une utilisation massive et/ou abusive, l’utilisation de cette action est réservée pour l’exécution requêtes SQL, Script, …

Local à un élément du projet

Les procédures déclarées dans un élément local du projet ont un portée local, elles ne sont pas accessibles depuis un élément extérieur. Le nom sera composé en 3 parties :
• Préfixe : Obligatoire et fixe «lProc ».
• Action : Obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions dans le paragraphe « Global au projet (Collections de procédures) ». 
• Nom : Obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en majuscule.

Les trois parties seront séparées par le caractère «_ ».

Exemple :

Classes

Les procédures de classes sont soit public, protégée, ou privée, dans la convention de nommage, cette notion n’est pas prise en compte, car lors de la programmation en objet, WinDev fait la complétion automatique en proposant uniquement les procédures avec une portée accessible. Le nom est composé de deux parties :
• Action : Obligatoire, cette partie permet en un mot de définir le type d’action de la procédure. Cf. liste des actions dans le paragraphe « Global au projet (Collections de procédures) ». Une exception est appliquée pour les procédures des gestions des requêtes, la partie action commence par « Exe »
• Nom : Obligatoire, il doit être explicite pour permettre à la lecture de comprendre le traitement de la procédure. Par convention le nom est écrit en minuscule, sans accent, sans caractère spéciaux (€,$,%, …), et commence par une minuscule. Si le nom de l’élément est composé de plusieurs mots, la première lettre du mot est en minuscule.

Exemple :

Les procédures (Et les fonctions ?)

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

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.