Remise en cause des manières de coder d'un très vieux développeur

Bonjour tous,
codant en windev, mais pas que, depuis quelques temps, j'ai certainement pris des habitudes et certaines de ces habitudes sont peut-être à remettre en question pour ne pas être trop largué d'ici à ma retraite.
Toutefois, j'ai du mal à comprendre l'utilisation de procédures globales ne contenant qu'une seule ligne et l'argument avancé pour justifier cet emploi, à savoir "éviter la redondance de code".

Illustration
Extrait de code

Code:

---

1 2 3 4 5 6 7 8

SI FG_FichierExiste(FichierDeConfig) ALORS SI FG_SectionExiste(NomSection,FichierDeConfig) ALORS slogin = FG_RendValeurIniLit(NomSection,"LOGIN",FichierDeConfig) sdatabase = FG_RendValeurIniLit(NomSection,"BASE",FichierDeConfig) smotdepasse = FG_RendValeurIniLit(NomSection,"PASSWORD1",FichierDeConfig) sserveur = FG_RendValeurIniLit(NomSection,"SERVEUR",FichierDeConfig) ...

---

avec

Code:

---

1 2 3 4

PROCÉDURE GLOBALE FG_FichierExiste(FichierATrouver)   SI fFichierExiste(ComplèteRep(fRepEnCours())+FichierATrouver) ALORS RENVOYER Vrai SINON RENVOYER Faux

---

et

Code:

---

1 2 3 4

PROCÉDURE GLOBALE FG_SectionExiste(NomSection,FicDeConfig)   SI SansEspace(INILit(NomSection, "BASE", "",ComplèteRep( fRepEnCours())+FicDeConfig)) <> "" ALORS RENVOYER Vrai SINON RENVOYER Faux

---

et

Code:

---

1 2 3 4

PROCÉDURE GLOBALE FG_RendValeurIniLit(ChoixSection,ParamVoulu,FichDeConfig) : chaîne   RENVOYER INILit(ChoixSection, ParamVoulu, "", fRepEnCours()+"\"+FichDeConfig)

---

Je ne vois absolument pas l'intérêt de ces 3 procédures, en l'état.

Est-ce la bonne manière "moderne" de coder, que ce soit en windev ou pas, d'ailleurs ?

Pouvez-vous m'éclairer à ce sujet ?

D'avance, merci pour vos lumières.

P.S.
Ce n'est pas un troll, bien que la période de Noël s'y prête.

Bonjour,

Étant moi même un "jeune" développeur en fin de carrière, j'avoue que je ne suis pas à même de juger des tendances actuelles.

Toutefois, je vais donner mon avis sur les fonctions que tu donnes en exemple.

Je dirais que seule la seconde <FG_SectionExiste(NomSection,FicDeConfig)> se justifie à mes yeux (et encore).

Les autres ne font qu'appeler une fonction existante dans Windev.

Et encore. Je n'aime pas les fonctions trop fermées. Par exemple, je fais d'utiliser fRepEnCours() pour le chemin du fichier ini, ne me plait pas. Ça signifie qu'il faudra une autre fonction si jamais on doit utiliser un fichier ini se trouvant dans un autre dossier.
Pareil pour le fait de mettre en dur "BASE" comme mot clef dans la fonction FG_SectionExiste. Quid d'une section n'ayant pas de mot clef "BASE" ? Il faut une autre fonction.

Bref, je n'aime pas ces codes. Mais ce n'est que mon avis.

JS

PS : Cette syntaxe

Code:

---

PROCÉDURE GLOBALE FG_RendValeurIniLit(ChoixSection,ParamVoulu,FichDeConfig) : chaîne

---

ressemble d'avantage à du Pascal qu'à du windev, non ? :koi:

Bonjour,
Ce qui est surtout à remettre en question, c'est l'utilisation d'un fichier INI.
Depuis plus de 20 ans, il est préconisé d'utiliser la BDR donc la fonction SauveParamètre à la place des fichiers INI. La seule exception est le multi plateforme (pas de BDR) mais dans ce cas, il suffit de passer ParamIni dans InitParamètre, le tout étant réglé par une compilation conditionnelle.

Code:

---

1 2 3 4 5 6 7 8 9

<COMPILE SI TypeConfiguration<>ApplicationWindows> InitParamètre(paramINI) <SINON> InitParamètre(paramRegistre,ChaineConstruit("%1ParamLogin",CompleteRep(ProjetInfo(piRegistre))) <FIN>   ChargeParametre("LOGIN",sLoginDefaut) ......

---

Citation:

---

Envoyé par Voroltinquo

Bonjour,
Ce qui est surtout à remettre en question, c'est l'utilisation d'un fichier INI.
Depuis plus de 20 ans, il est préconisé d'utiliser la BDR donc la fonction SauveParamètre à la place des fichiers INI. La seule exception est le multi plateforme (pas de BDR) mais dans ce cas, il suffit de passer ParamIni dans InitParamètre, le tout étant réglé par une compilation conditionnelle.

---

Oui tout à fait d'accord sur le principe. Mais il s'agit d'une configuration webservice. Les fonctions Registrexx ne sont pas autorisées et si elle l'étaient le WS pouvant être potentiellement déployé sur un OS autre que windows ...

Citation:

---

Envoyé par Christophe Charron

si elle l'étaient le WS pouvant être potentiellement déployé sur un OS autre que windows ...

---

C'est bien pour cela que je parlais de compilaton conditionnelle.
Si on est dans le cas d'un autre OS, c'est le Fichier INI qui est lu (resp écrit) via Charge (resp Sauve) paramètre. Il n'y a pas d'utilisation des fonctions RegistreXXX.
La valeur par défaut étant passée dans la fonction de lecture.

Ce code est un choix d'un développeur particulier (dont les initiales sont FG ?), ce n'est pas la norme de tous les développeurs.

Et a priori, ce développeur ne connaissait pas la surcharge de fonction. (cf documentation )

Ici, je pense que l'idée c'était de 'déporter un problème'. Il veut pouvoir faire évoluer son application, en gérant les répertoires d'une façon ou d'une autre ... Dans le code proprement dit, il ne fait aucune références aux répertoires.
Et dans cette fonction FG_FichierExiste(), il s'occupe des répertoires.
Dans la version qu'on voit ici, les répertoires sont gérés d'une certaine façon. J'imagine que le développeur prévoyait de faire évoluer cette fonction. Ou que le développeur a fait évoluer cette fonction. Il avait peut-être des noms de répertoires autres dans des versions précédentes, pour faire des tests, et il a changé les noms pour cette version finale.

Bonjour,

Je suis un vieux jeune (ou jeune vieux) développeur comme JS.

Concernant l'utilité de tes procédure, je rejoins JS (encore). Elles sont plutôt inutiles et pire avec des choses en dur pour la 2°.

Concernant les fichiers ini, je ne suis pas d'accord avec (l'excellent) Voroltinquo concernant la BDR. L'utilisation de la BDR, ne fonctionnerait pas avec notre appli (client serveur). Les paramètres de connexion à la base sont dans un fichier ini, par exemple. L'ensemble des paramètres communs est dans un fichier (table) Table_Param de la BDD.
Dernier point concernant les fichiers INI : le changement de serveur. Il est plus facile de faire un copier-coller du répertoire de l'exe (et du fichier ini compris dedans) que de faire en plus l'export/import, sans parler du re-paramétrage. Mais, ce n'est que mon avis et mon mode de fonctionnement. ;)

Citation:

---

Envoyé par tbc92

Ce code est un choix d'un développeur particulier (dont les initiales sont FG ?)...

---

Je pense plutôt que c'est un préfixage (Fonction Globale).

Je suis comme Frenchsting, j'utilise les fichiers ini, plus que la BDR.

Et, encore comme Frenchsting, je place les paramètres dans une table de la bdd. Le fichier ini ne servant que pour les indications de connexions à la base de données.

JS

Perso j'utilise peu la BDR car trop restrictif à un seul utilisateur. je stocke tous mes paramètres en BDD dans un json comme ça je n'ai aucune limite.

Comme @Jon Shannow, je n'utilise le fichier ini que pour les infos de connexion.

Bonjour,

je suis aussi Frenchsting sur le INI. Nous l'utilisons toujours pour stocker l'adresse de la base :

- le type de base (CS ou Classique)
- Le chemin base si classique
- Le port et IP si CS

C'est beaucoup plus simple lors d'ajout de nouveau poste ou de changement de config car on peut le déployer très facilement

Par contre tout le reste est stocké dans la BDD

Citation:

---

Envoyé par tbc92

Ce code est un choix d'un développeur particulier (dont les initiales sont FG ?), ce n'est pas la norme de tous les développeurs.

Et a priori, ce développeur ne connaissait pas la surcharge de fonction. (cf documentation )

Ici, je pense que l'idée c'était de 'déporter un problème'. Il veut pouvoir faire évoluer son application, en gérant les répertoires d'une façon ou d'une autre ... Dans le code proprement dit, il ne fait aucune références aux répertoires.
Et dans cette fonction FG_FichierExiste(), il s'occupe des répertoires.
Dans la version qu'on voit ici, les répertoires sont gérés d'une certaine façon. J'imagine que le développeur prévoyait de faire évoluer cette fonction. Ou que le développeur a fait évoluer cette fonction. Il avait peut-être des noms de répertoires autres dans des versions précédentes, pour faire des tests, et il a changé les noms pour cette version finale.

---

Bonjour à tous et merci pour vos points de vue.
Comme l'a compris frenchsting, FG_ correpond au préfixe des fonctions globale.
Et non, il ne connaissait pas la surcharge de procédures que nous employons essentiellement pour une gestion plus fine des erreurs avec leur traçage dans la BDD.

Je reviens sur ma question de départ : ces fonctions globales sont-elles nécessaires et apportent-elles une valeur ajoutée "factorisation" de code, sachant que le .cfg n'est lu que dans cette procédure, puisque le fichier de configuration ne contient que les informations nécessaires à la connexion à la BDD et que ces fonctions ne comportent qu'une ligne de code appelant une fonction windev.
Personnellement, j'ai préconisé de tout rassembler dans la même procédure, au pire en utilisant une procédure interne, mais à mon sens tout aussi inutile.

Bonjour,

Un avis rapide sur ce sujet :
- pour la procédure FichierExiste, l'intérêt est faible voire même inutile à mes yeux
- Pour les procédures sur le fichier, je dirai que cela permet de limiter/d'éviter des erreurs de saisie sur la section et la valeur recherchée.
Ce qui me faire dire cela, c'est le mot "BASE" qui si il est répété x fois dans le code peut être mal écris (ex "BSAE"). Ensuite, si une modification doit être faite sur ce mot-clé, la modification est faite à un seul endroit.

Sinon je suis pour le fichier INI :)

Bonjour,
Pour ma part je préfère utiliser des variables et/ou constantes globales au projet.
Par exemple ici on a une répétition de fRepEnCours()+"\"+FichDeConfig.
Autant déclarer cette valeur une fois dans l'Init du projet, ainsi en cas de changement il ne faut la modifier qu'à un seul endroit, et du coup on peut utiliser les fonctions Windev sans surcharges.
D'ailleurs il manque un ComplèteRep() dans la procédure FG_RendValeurIniLit()... CQFD.

Tatayo.

J’adore ces codes, et j’aimerais énormément que ce soit plus répandu. Le concept DRY est un concept fracassé dans les applis Windev que j’ai eu à maintenir, c’est pourtant l’un des concepts fondamentaux du développement. Quand la redondance peut être évitée, elle DOIT l’être. Il sont extrêmement rares, les cas où j’ai du me résoudre à redonder. A vrai dire, ça a du arriver 2 ou 3 fois en 10 ans.

Pour FG_FichierExiste : un simple RENVOYER suffit, sans le SI. Car fFichierExiste renvoie déjà un booléen; c’est du détail. Pour les autres fonctions ok. Et je ne suis pas du tout choqué qu’il fasse une fonction pour en «*surcharger*» une autre. Pour les valeurs en dur dans la fonction, tant qu’elles ne sont qu’à un seul endroit, je n’ai rien à dire. Si il doit les utiliser ailleurs, il faudra les factoriser aussi. Evidemment là c’est du procédural donc si ça arrive, il va me coller une globale dans le code du projet (seigneur) au lieu de me faire une fonction get. En POO c’est l’objet qui porte ces constantes, souvent dans des property.

La surcharge directe d’une fonction découle d’une envie de modifier le comportement de la fonction. Ce qu'il fait là haut n'est pas de la surcharge car il n'a rien changé dans le comportement des fonctions. Le terme "surcharge" est employé un peu vite, je fais très peu de surcharges "réelles". Si vous en faites trop, il est de bon ton de se demander si le framework que vous utilisez est adapté à votre besoin, car visiblement, vous en changez trop les comportements.

Je crée moi même des fonctions qui parfois, n’ont qu’une ligne, et c’est particulièrement le cas en objet, puisque je fais quasi exclusivement de la POO. Plusieurs property ou fonctions n’ont souvent qu’une ligne, car la valeur qu’elles vont renvoyer est ainsi factorisée dans la classe.

Je ne surcharge pas les fonctions WLangage car je ne souhaite pas modifier leur comportement; juste factoriser leur utilisation. J’ai du une fois surcharger Trace car il ne gérait pas des fenêtres de Trace multiple, et là oui, j’ai directement surchargé Trace pour que tout appel dans le code fasse appel à cette fonction modifée qui n'utilisait pas la fenêtre Trace (ni même la fonction Trace de Windev d'ailleurs) mais une fenêtre que j'avais créée.

Sans oublier qu’une surcharge est valable dans tout le programme, et je ne souhaite pas forcément que d’autres parties du programme appellent une fonction modifiée, je veux l’originale.
«*Oui, on peut avoir l’originale avec WL.Mafonction*», oui, mais je le sais car c’est moi qui code. Si demain je pars et que le projet est repris par un autre développeur, lui éviter de gérer des surcharges inutiles et en rester à des fonctions qui ne nécessitent pas de surcharger les fonctions du framework rendra la maintenabilité plus élevée.

Plus récemment: je développes des Webservices qui ont donc un appel à WebserviceEcritCodeHTTP en cas d’erreur. J’avais factorisé cette fonction dans une fonction perso qui encapsulait l’appel à WebserviceEcritCodeHTTP. Au premier abord, ça paraissait inutile, quand Windev a changé le comportement des renvois d’erreurs, ça m’a directement sauvé. Si j’avais appelé WebserviceEcritCodeHTTP à chaque endroit du code ou j’en avais besoin, j’étais parti pour modifier 100 références. Bon courage.

Pour répondre aux points divers, voici mes avis:
-jamais de BDR, toujours des fichiers INI. La BDR est un concept Windows, à l’heure du web et du multiplateforme, mes conceptions prennent toujours en compte le fait qu’un jour le code pourrait se retrouver sur un autre OS que Windows. Et ça n’est pas dix ans après qu’il faut se poser la question car le refurb devient trop cher et impossible. J’ai connu des projets coincés comme ça

-pas de globales à outrance. Si des variables doivent être accessibles dans tout le programme, et en POO ça n’est pas si fréquent, ce sera un singleton qui s’en chargera. J’ai régulièrement vu du code Legacy contenir des centaines de variables globales dans le code du projet, et là clairement, je n’y vais pas par 4 chemins: c’est une horreur en débug et en factorisation. C’est l’un des tout premiers points qui m’a été enseigné en BTS d’ailleurs, par mon prof de C.

-j’ai lu «*tout rassembler dans une procédure avec des fonctions internes*» ça s’appelle une fonction godlike. Et c’est une horreur. Une fonction fait UNE chose, et elle la fait bien. Si la fonction fait plusieurs choses son débug et sa factorisation seront difficiles à assurer, et sa surface de bug sera augmentée. Les procédures internes sont à user avec parcimonie, essentiellement elles me servent lors des parcours récursif (introspection d’objets imbriqués par exemple)

Le débat de fond, c'est de savoir si le découpage des fonctions, la factorisation, doit être fait de manière très profonde. On a l'impression en voyant ces fonctions que c'est le cas ce qui donne lieu à pas mal d'échanges sur ce fil, mais je prends le contrepied: pas pour moi. Il code juste de façon....normale.
Car si il voulait factoriser encore plus, il le pourrait:

Code:

---

SI fFichierExiste(ComplèteRep(fRepEnCours())+FichierATrouver) ALORS RENVOYER Vrai SINON RENVOYER Faux

---

Si je factorise fRepEncours et le FichierATrouver, 2 valeurs que je voudrais surement customiser un jour et sur lesquelles je pourrais créer une fonction pour "surcharger" la valeur renvoyée, je pourrais. Mais là ça rendrait le code un peu imbuvable quand même, car le trop est l'ennemi du pas assez. Et je suis d'accord, ça serait trop factorisé.

Globalement dans les projets que j'ai vu, on est pas dans le "pas assez", on est dans le "pas du tout". Et c'est dangereux, j'ai déjà croisé plusieurs projets dans ma carrière qui en sont au point mort pour toute ces raisons. Qu'est ce qu'on fait du coup? On repart de zéro, où on attends que le temps passe.

Précision: à l'heure ou j'écris ces lignes, j'ai 29 ans.