8
août
2013
Windev : Norme de programmation pour les procédures et les champs graphiques
août
2013
Un article de dsr57
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.
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 :
-
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=vraiPour 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+"'"
finJusque 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.
-
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
1 Commentaire + Ajouter un commentaire
Commentaires récents
- dans Héritage en WinDev : BUG ou subtilité du W-langage???
- dans Héritage en WinDev : BUG ou subtilité du W-langage???
- dans Héritage en WinDev : BUG ou subtilité du W-langage???
- dans Héritage en WinDev : BUG ou subtilité du W-langage???
- dans Windev : Norme de programmation pour les procédures et les champs graphiques
merci