Blog de dsr57 – Windev

Un article de dsr57    Pas de commentaires

Voilà, je me lance enfin dans la rédaction d’un blog.

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