IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

WinDev Discussion :

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


Sujet :

WinDev

  1. #1
    Membre confirmé Avatar de Christophe Charron
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2005
    Messages
    917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2005
    Messages : 917
    Points : 606
    Points
    606
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    PROCÉDURE GLOBALE FG_FichierExiste(FichierATrouver)
     
    SI fFichierExiste(ComplèteRep(fRepEnCours())+FichierATrouver) ALORS RENVOYER Vrai SINON RENVOYER Faux
    et
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Cordialement,
    Christophe Charron

  2. #2
    Membre extrêmement actif Avatar de Jon Shannow
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2011
    Messages
    3 948
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : avril 2011
    Messages : 3 948
    Points : 8 249
    Points
    8 249
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    PROCÉDURE GLOBALE FG_RendValeurIniLit(ChoixSection,ParamVoulu,FichDeConfig) : chaîne
    ressemble d'avantage à du Pascal qu'à du windev, non ?
    Au nom du pèze, du fisc et du St Estephe
    Au nom du fric, on baisse son froc...

  3. #3
    Membre expert
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    juin 2017
    Messages
    2 174
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : juin 2017
    Messages : 2 174
    Points : 3 836
    Points
    3 836
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)
    ......
    Il y a peut être plus simple, mais ça tourne

  4. #4
    Membre confirmé Avatar de Christophe Charron
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2005
    Messages
    917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2005
    Messages : 917
    Points : 606
    Points
    606
    Par défaut
    Citation Envoyé par Voroltinquo Voir le message
    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 ...
    Cordialement,
    Christophe Charron

  5. #5
    Membre expert
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    juin 2017
    Messages
    2 174
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : juin 2017
    Messages : 2 174
    Points : 3 836
    Points
    3 836
    Par défaut
    Citation Envoyé par Christophe Charron Voir le message
    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.
    Il y a peut être plus simple, mais ça tourne

  6. #6
    Rédacteur/Modérateur

    Homme Profil pro
    Ingénieur qualité méthodes
    Inscrit en
    décembre 2013
    Messages
    3 563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur qualité méthodes
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2013
    Messages : 3 563
    Points : 8 236
    Points
    8 236
    Par défaut
    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.
    N'oubliez pas le bouton Résolu si vous avez obtenu une réponse à votre question.

  7. #7
    Expert éminent
    Avatar de frenchsting
    Homme Profil pro
    mutlitâche-multifonction
    Inscrit en
    juin 2003
    Messages
    4 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : mutlitâche-multifonction
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2003
    Messages : 4 382
    Points : 7 535
    Points
    7 535
    Par défaut
    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 Voir le message
    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).
    Commencez toujours appuyer sur la touche F1 et puis n'hésitez à passer par un moteur de recherche...
    Le forum est fait pour répondre aux questions : pas la peine de me les envoyer par MP. Merci.

    Make it real not fantasy.

  8. #8
    Membre extrêmement actif Avatar de Jon Shannow
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2011
    Messages
    3 948
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : avril 2011
    Messages : 3 948
    Points : 8 249
    Points
    8 249
    Par défaut
    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
    Au nom du pèze, du fisc et du St Estephe
    Au nom du fric, on baisse son froc...

  9. #9
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2003
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : mai 2003
    Messages : 879
    Points : 1 683
    Points
    1 683
    Par défaut
    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.
    Philippe,


    N'hésitez à lever le pouce si mon aide vous a été utile.

  10. #10
    Membre régulier
    Homme Profil pro
    Inscrit en
    juin 2011
    Messages
    81
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 81
    Points : 91
    Points
    91
    Par défaut
    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

  11. #11
    Membre confirmé Avatar de Christophe Charron
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2005
    Messages
    917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2005
    Messages : 917
    Points : 606
    Points
    606
    Par défaut
    Citation Envoyé par tbc92 Voir le message
    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.
    Cordialement,
    Christophe Charron

  12. #12
    Membre expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    2 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2004
    Messages : 2 218
    Points : 3 646
    Points
    3 646
    Par défaut
    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

  13. #13
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 863
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 863
    Points : 11 743
    Points
    11 743
    Par défaut
    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.

  14. #14
    Membre confirmé
    Homme Profil pro
    Chef de projet
    Inscrit en
    mars 2017
    Messages
    268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Chef de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2017
    Messages : 268
    Points : 613
    Points
    613
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 20/10/2010, 11h27
  2. #include bidirectionnel cause des problèmes
    Par matrox dans le forum C++
    Réponses: 4
    Dernier message: 21/06/2006, 16h46
  3. [VB6]Problème dajout dans une Table Access à cause des group
    Par bb62 dans le forum VB 6 et antérieur
    Réponses: 6
    Dernier message: 01/02/2006, 10h06
  4. Problème d'addition à cause des NULL
    Par Oluha dans le forum Langage SQL
    Réponses: 6
    Dernier message: 29/03/2005, 13h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo