Projet:Scribunto/Guide/Structure Lua 2

Introduction

Le code sert à structurer les tests et actions à faire (en fonction des paramètres généralement), dans le but de générer du code wiki, que ce soit du texte simple ou de la structuration d'information (catégories, box, liens…).

Regrouper le code dans des fonctions

Lorsque le code génère du simple texte ce n'est pas très important, mais lorsqu'on génère du code wiki structurant il est important de regrouper ce code dans des fonctions (voire, s'il y en a assez, dans un module distinct). L'intérêt est double :

• comme pour tout code structuré cela permet de réutiliser les codes − en évitant les duplications − et ça simplifie à la fois la lecture et la modification du code
• cela permet surtout de regrouper tout ce qui touche aux données et/ou à la mise en forme, et facilite l'adaptation éventuelle du code en cas de changement de mise en forme

Sur ce dernier point il est d'ailleurs possible/probable que si les modules Lua se généralisent les briques de base servant à générer des choses finissent par devenir des modules. Cette structuration facilite(ra) alors l'extraction du code ou sa gestion par d'autres personnes.
Un exemple dans les infobox pourrait être la création de modules fournissant les fonctions qui correspondent aux briques de base des infobox (infobox début, infobox image, infobox titre, …). Chacun pourra inclure le module gérant ces briques de base et les utiliser sans (quasiment) modifier son code.

Aller plus loin : séparation code/données/sortie

Dans un module complexe on va trouver plusieurs niveaux :

• la structure logique du code (son « ossature ») : cela correspond aux actions à faire, dans quel ordre, en fonction de quelles informations
• les données brutes : ce sont par exemple des listes de paramètres valides, des listes de liens ou de codes…
• les éléments structurant la sortie générée : construction de catégories, de sections, de box, mise en forme communes…

Il paraît important de séparer ces différents éléments dans des fonctions différentes, mais aussi dans des modules distincts. L'intérêt est multiple, au delà de séparer le code en morceaux plus « digestes ».
Pour les données brutes :

• elles sont à part (avec leurs fonctions de manipulation, éventuellement), donc il est plus simple de corriger/ajouter/supprimer des entrées
• si un travail de traduction est nécessaire il est facile d'identifier les éléments à changer
• il est même possible d'avoir un module de données par langue et de charger dynamiquement celui désiré, chose plus complexe si tout est regroupé au sein d'un même module (sans parler de la taille du module, plus lourd à charger)

Pour les éléments structurant la sortie :

• elles sont à part donc plus simple à gérer, modifier, corriger (on n'a que la mise en structure sous les yeux)
• il est plus simple de changer de structuration de la sortie : on ne change que ça
• on peut même (comme pour les données) avoir plusieurs « styles », chacun dans un module, et charger celui voulu à l'exécution
• cela simplifie à terme l'utilisation de fonctions globales/standards générant du code de formatage (exemple réel : il n'existe pas actuellement de fonction interne pour créer des liens (internes, externes, vers des diffs, les pages de discussions…). Si un code qui fait cela a ces fonctions regroupées il sera simple le jour où ces fonctions seront disponibles de modifier le code à faible coût

Pour la structuration du code :

• le code est plus court, donc plus simple à lire et à comprendre (et donc à modifier)
• l'export des données et de la mise en forme ne laisse dans le code que ce qui relève de l'agencement logique des éléments en fonction des données : il est plus simple de comprendre et de valider le fonctionnement du code