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 :

• Nouveauté 36 : graphes, nouvel aspect des bulles

Une amélioration intéressante pour l’utilisateur finale pour faciliter la lecture d’un graphe.

• Nouveauté 37 : Mire de lecture de graphe

Pour la même raison que la nouveauté 36, une amélioration intéressante pour l’utilisateur

• Nouveauté 46 : Une fenêtre D’IHM + une fenêtre de code simultanément à l’écran

Avec cette nouveauté, l’espace de travail s’améliore. un écran pour l’interface et un autre pour le code. Reste à convaincre les responsable des achats pour un deuxième écran

• Nouveauté 53 : Ordre de tabulations recalculé a chaque modification

Avec cette nouveauté, fini les oublis lors d’une modification d’IHM effectuée dans la dernière ligne droite du projet.

• Nouveauté 54 : Utilisation des ancrages en redimensionnement

Cette nouveauté entraîne un gain de temps et un respect des proportions existantes lors de modification d’IHM.

• Nouveauté 59 : Erreur d’IHM, champs avec bulles d’aide identiques signalées

Allez soyons honnête … Vious n’avez jamais oublier de modifier la bulle d’aide. Avec cette nouveauté WinDev nous le rappellera en erreur d’IHM.

• Nouveauté 63 : Centraliser les codes de mise à jour des champs d’une fenêtre
Alors cette nouveauté, c’est surement celle que je trouve la plus … à mon gôut au sens développement et lisibilité du code. Dans mes développements et mes explications sur WinDev je met en avant la centralisation du code de mise à jour des IHM dans les fenêtres pour :
• centraliser le code
• améliorer la lisibilité
• faciliter la ré utilisabilité
• faciliter les modifications

Je ne peux que inciter à l’utilisation de ce nouveau traitement

• Nouveauté 91 : MVP, comment l’utiliser facilement

Après la centralisation du code dans la nouveauté 63, la séparation des actions avec le Design Pattern MVP.
Impatient de voir le code à mettre en place pour utiliser ce Design Pattern

• Nouveauté 92 : Procédure interne

Avec cette nouveauté, on va pouvoir un niveau d’encapsulation et permette de diviser des parties de programmes procédural en sous taches qui n’ont d’intérêt et de sens que localement. Cela permet d’éviter l’accumulation de fonction globale qui ont un usage très restreint.

• Nouveauté 95, 96, 97 : Programmation parallèle

Ensemble de nouveautés intéressantes pour faciliter la programmation parallèle.

• Nouveauté 109 : Affectation multiples groupées

Enfin, un des gros manques des versions précédentes, je n’ai jamais compris pourquoi on pouvais déclarer sur une seule ligne des variables mais qu’il fallait plusieurs ligne ou bloc de code pour initialiser plusieurs variables

• Nouveauté 113 : Design Pattern façade (objets associés)

Cette nouveauté augmente les possibilités POO de WinDev.

• Nouveauté 125 : Coordonnées géographique, fonctions géoAzimuth et géoDistance

Ces deux fonctions sont très intéressantes pour des logiciels utilisant des cartes, des adresses, des tournées, …

• Nouveauté 203 : Jauge à progression infinie

Cette nouveauté met fin au code à plusieurs états pour afficher correctement une jauge infinie

Conclusion

Cette version de Windev emmène des nouveautés intéressantes autant que ce soit au niveau développement que graphique pour le client. Le nombre de 920 me parait gonflé, mais ça c’est l’aspect commercial, et cela devient une question d’habitude. Chacun qui verra un intérêt à migrer ou pas

Modification apportée le 11.12.2013 grâce à une précision de zechatdoc.

L’Héritage c’est quoi ?

• Utiliser les champs hérités de la classe de base ( selon leur visibilité).
• Ajouter des nouveaux champs.
• Utiliser une méthode héritée ( selon la visibilité).
• Redéfinir une méthodes en la créant avec la même signature.
• Surcharger une méthode en la créant avec un signature différente.
• Ajouter une nouvelle méthode.
• Ajouter un ou plusieurs constructeur.

L’héritage par Windev par l’exemple

• Définition de l’exemple
Pour évoquer la notion d’héritage en Windev, je vais créer deux classes
ac_voiture : Classes pseudo abstraite (Cf un futur article sur les classes abstraites en windev) représentant une voiture.
pc_peugeot : Classes héritant de ac_voiture représentant une voiture de marque « Peugeot ».

Membres de la classe ac_voiture

PROTÉGÉE 
    ls_marque est une chaîne
    ls_modele est une chaîne
GLOBALE
    li_nbVoiture est un entier

Les membres ont des propriétés en lecture/éciture

//----->Propriété
PROCEDURE Marque() //Lecture
RENVOYER :ls_marque

PROCEDURE Marque(ps_marque est une chaîne) //Ecriture
:ls_marque = ps_marque

PROCEDURE Modele() //Lecture
RENVOYER :ls_modele

PROCEDURE Modele(ps_modele est une chaîne) //Ecriture
:ls_modele = ps_modele

Membres de la classe pc_peugeot

hérite de ac_voiture
PRIVÉE
    lb_moteurHdi est un booléen

Le membre a des propriétés en lecture/écriture

PROCEDURE moteurHdi() //Lecture
RENVOYER :lb_moteurHdi

PROCEDURE moteurHdi(pb_moteurHdi est un booléen) //Ecriture
:lb_moteurHdi = pb_moteurHdi
• Constructeur sans paramètre
Pour continuer notre exemple, nous allons créer le constructeur par défaut (Constructeur sans paramètre) pour chacune des classes.

Constructeur ac_voiture

PROCEDURE PROTÉGÉ Constructeur()
//---->Pas de code

Constructeur pc_peugeot

PROCEDURE Constructeur()
Ancêtre:Constructeur()
La première ligne fait appel au constructeur de la classe de base, WinDev n’oblige pas cet appel et ne l’effectue pas automatiquement (Cf langage JAVA), mais pour des questions de maintenance, de lisibilité et de compréhension, j’effectue toujours cet appel.
• Programme principale

Dans le code d’initialisation de la fenêtre je vais instancier un objet de type pc_peugeot.

lo_peugeot est un pc_peugeot()
• Constructeur avec paramètres.
Dans cette étape je supprime les constructeurs par défaut et supprime l’accès en écriture des membres. Je re-code des constructeurs en passant en paramètre les valeurs initialisation des membres. De cette façon, je force l’initialisation des membres de la classe par le constructeur.

Constructeur de la classe ac_voiure

PROCEDURE PROTÉGÉE  Constructeur(ps_marque est une chaîne,ps_modele est une chaîne)

:ls_marque=ps_marque
:ls_modele=ps_modele

Constructeur de la classe pc_peugeot

PROCEDURE Constructeur(ps_marque est une chaîne,ps_modele est une chaîne, pb_hdi est un booléen)

Ancêtre:Constructeur(ps_marque,ps_modele)
:lb_moteurHdi=pb_hdi

Au niveau de mon code principal, j’effectue certaines modification :

lo_peugeot est un pc_peugeot("Peugeot","308",Vrai)

Le code se compile, mais j’ai une erreur lors de l’exécution.

Erreur à la ligne 0 du traitement Constructeur de la classe pc_peugeot.
Les paramètres d’appel du code ‘Constructeur de la classe ac_voiture’ sont incorrects : on attendait 2 paramètres et on en a reçu 0.

Apres quelques recherches, j’ai isolé la ligne de code qui posait problème

hérite de ac_voiture

Si je traduis l’erreur de WinDev, à cette ligne de code, WinDev attend les 2 paramètres du constructeur de la classe ac_voiture. Cela veut dire que quand je déclare un objet de type pc_peugeot. Avant même que le constructeur de la classe instanciée soit appelé, le constructeur de la classe de base est appelé. Pour vérifier cette hypothèse, je vais ajouter une ligne trace dans le constructeur de la classe ac_voiture et recréer le constructeur par défaut (Pour ne pas avoir l’erreur d’exécution).
PROCEDURE PROTÉGÉE  Constructeur(ps_marque est une chaîne,ps_modele est une chaîne)

:ls_marque=ps_marque
:ls_modele=ps_modele

Trace("Marque : "+:ls_marque+" - Modele : "+:ls_modele)
PROCEDURE PROTÉGÉE Constructeur()

Trace("Marque : "+:ls_marque+" - Modele : "+:ls_modele)

Le résultat de la trace

Marque : – Modele :
Marque : Peugeot – Modele : 308

Mon hypothèse est validée, lors de l’instanciation d’un objet héritant d’une classe de base, Windev appelle automatiquement le constructeur de la classe de base. Ce qui me pose problème, c’est que cet appel n’est pas effectué dans le constructeur, mais lors de la liaison d’héritage : Hérite de ac_voiture.

Conséquences …

Rappel : Les membres statiques sont des champs ou méthodes qui sont accessibles par la classe elle même ou par toutes les instances de la classe. on parle également de membres partagés. Ils son très utiles lorsque vous avez à gérer dans une classe des informations qui ne sont pas spécifique à une instance de classe mais à la classe elle même.

Classe ac_voiture

Ajout du membre statique li_nbvoiture, déclaration de la classe

Propriété en lecture pour le membre li_nbVoiture

Modification du constructeur (Par défaut) pour incrémenter le membre statique

Classe pc_peugeot

Ajout du membre statique li_nbPeugeot

Propriété en lecture pour le membre li_nbPeugeot

Modification du constructeur (Par défaut) pour incrémenter le membre statique

Nous venons de terminer l’ajout des membres statiques à nos classes, maintenant nous allons modifier le code principale pour avoir afficher dans une trace le nombre de voiture et le nombre de peugeot instancié.

Résultat de la trace :

Voiture : 2 – Peugeot : 1

J’obtiens 2 voitures dont une Peugeot alors que je n’ai instancier qu’un seul objet.

Voila une des conséquences des appels prématurés automatiques, les données du programme sont erronées.
Ensuite je vais aussi insister sur le faite que nous sommes obligés d’avoir un constructeur par défaut dans la classe de base pour pouvoir mettre en place un héritage.

La subtilité

Conclusion

Les classes

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 :

Exemple :

Les membres

Exemple :

Les méthodes

Héritage

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.

Mon premier billet évoque les normes de programmation dans une équipe de développement, une SSII. Plus particulièrement, celle que j’utilise au quotidien sur l’EDI WinDev, Ce billet évoquera dans un premier temps le but d’une norme de programmation, pour ensuite répondre à la question « Pourquoi ne pas utiliser la charte de WinDev ?« , et pour terminer sur l’explication de la norme des variables de type simples. Dans de futurs billets, je reviendrai sur une norme en POO, et sur les champs graphiques …

Introduction

De mon expérience de développeur, j’ai pu constaté l’absence quasi systématique de la mise en place de normes de programmation au sein d’une équipe de développement. Chaque développeur, travaille dans son coin, sur son projet, sans réellement se soucier de la lisibilité, compréhension de son code… Les entreprises pensent à harmoniser le visuel des logiciels par une charte graphique, mais ne vont jamais jusqu’à harmoniser le code, et pourtant ces normes sont importantes.

Une norme, pourquoi ?

Pour comprendre, le réel but d’une norme de programmation, il faut raisonner en terme d’équipe, et d’entreprise. Pour le bon fonctionnement d’un service de développement, chacun doit pouvoir se substituer à l’autre, c’est dans ce but que le respect d’un certain nombre de règles renforce la valeur d’une équipe de développement, et l’entreprise gagne en productivité. Suit, un certain nombre d’arguments que j’avance pour la mise en place d’une norme :
• Harmoniser le code.

Comme évoqué en introduction, les entreprises pensent à une mettre en place une charte graphique pour les utilisateurs finaux, mais il arrive que l’on oublie (trop souvent à mon goût)de mettre en place des normes de programmation.Si le nom des variables, champs, objets, fenêtre, … respecte une même règle, il devient tout de suite plus simple de se retrouver dans du code, et de comprendre l’utilité de chaque élément.

• Faciliter la compréhension du code aux autres développeurs.

Sur un même projet nous aurons peut être autant de possibilités de codes que de développeurs différents (enfin presque). Les collègues qui repassent derrière d’autres, vont devoir comprendre l’ensemble des lignes avant de trouver la source du BUG, ou l’endroit à insérer une modification. Si par une simple norme de programmation on évite une réflexion pour la compréhension des variables, type de champs, objets. c’est un gain de temps.

• Faciliter la ré-lecture de son code.

Oui, çà arrive à tout programmeur de se dire : « Mais qu’est ce que j’ai voulu faire », en ne comprenant pas l’utilité d’une variable.

WinDev, presque parfait ?

Windev permet de définir au niveau du projet une charte de programmation. Ce paramètre est accessible au menu Projet, Description du projet, Onglet Option. Activer l’option « Activer le préfixage automatique des variables et des éléments du projet » (Cf Fig.1).

Vous pouvez l’éditer, la modifier, mais même si Windev a évolué depuis les dernières versions, L’EDI a encore des manques. Par exemple la gestion de la portée, la différence entre une fonction et une procedure.

Sur la portée, Windev affiche de couleurs différentes les variables selon leur portée.

Attention, si on se base sur des couleurs, on peut se faire piéger, et WinDev ne va pas assez loin sur la portée :
• Les couleurs peuvent varier d’un écran à l’autre.
• Quand je lis une variable je ne veux pas avoir mon panel de couleurs à proximité pour connaitre sa portée.
• Windev ne fait pas la différence entre une variable globale et une variable passée en paramètre.

Pour les procédures, WinDev ne permet pas de faire la différence entre une fonction (Qui retourne une valeur) et une procédure.

La norme

Après avoir expliqué pourquoi une norme, et la limite de WinDev, ces deux paragraphes appuient sur l’utilité d’une norme. Celle que j’utilise permet d’identifier en une lecture : la portée, le type et l’utilité. Dans un premier temps nous allons voir la construction du nom d’une variable, ensuite la légende des portées et des types et pour finir une liste d’exemples.

Construction du nom d’une variable

Le nom d’une variable est constituée en 3 parties :
• La portée : Première lettre.
• le type : De la deuxième lettre au symbole « _ ».
• Le nom : Tout ce qui est après le symbole « _ ». Pour cette partie, utiliser un nom explicite et éviter les noms du type var1, var2. le nom commence par une minuscule et chaque changement de mot commence par une majuscule.

Exemple :

Avec un nom explicite, on est capable d’identifier que cette variable va stocker le nombre de détails de la facture, qu’elle est locale et de type entier (Cf. légende type).

La portée :
• G : Globales au projet
• g : globale à la fenêtre ou à l’état.
• l : local
• p : paramètre

Le type de variable :
• s : Chaine de caractère (String).
• i : Entier (Integer).
• f : Réel (Float).
• m : monétaire.
• d : Date
• h : Heure
• dh : DateHeure

Exemple de déclarations de variables :

Voilà, ce premier billet s’achève, A très bientôt