Pourquoi la discipline de typage revient dans les projets logiciels
La question revient régulièrement dans les équipes qui maintiennent du code ancien : faut-il continuer à écrire du Pascal, ou le traiter comme une dette technique à éliminer ? La réponse dépend moins du langage que de la manière dont il est employé. Un code Pascal structuré, typé et documenté se maintient sans difficulté particulière. Un code Pascal accumulé sans règles devient en revanche très coûteux à faire évoluer.
Le langage impose déjà un certain nombre de contraintes utiles. Le typage fort, la déclaration explicite des variables et la séparation entre interface et implémentation dans les unités orientent naturellement vers une organisation lisible. Ces propriétés ne suffisent pas à garantir la qualité, mais elles réduisent une partie des erreurs détectables à la compilation.
Structurer les unités et limiter leur surface d'exposition
En Pascal, l'unité est l'unité de compilation de base. Sa section interface déclare ce qui est visible de l'extérieur ; sa section implementation contient le reste. Ce découpage fonctionne comme une frontière de module et mérite d'être traité comme tel.
Une bonne pratique consiste à n'exposer dans l'interface que ce qui est réellement nécessaire aux appelants. Les fonctions utilitaires, les types intermédiaires et les variables globales internes restent dans l'implémentation. Cette discipline évite qu'un module devienne un dépotoir dont dépendent progressivement tous les autres.
Les dépendances entre unités doivent rester acycliques. Une unité qui utilise une autre ne doit pas être utilisée en retour par celle-ci, au risque de créer des couplages difficiles à démêler. Le compilateur signale d'ailleurs ces cycles, ce qui constitue un garde-fou appréciable.
Nommer, typer et documenter sans ambiguïté
Le Pascal tolère les identifiants courts, héritage des débuts du langage. Cette tolérance n'oblige pas à s'en servir. Des noms explicites pour les variables, les procédures et les types facilitent la relecture, en particulier lorsque le code est repris par une autre personne.
L'usage de types nommés plutôt que de types primitifs répétés apporte un gain réel. Déclarer un type TMontant = Currency ou TIdentifiantClient = LongInt documente l'intention et permet de faire évoluer la représentation à un seul endroit. Cette pratique reste méconnue dans de nombreux projets Pascal, où les types bruts sont utilisés partout.
La documentation des procédures publiques, même succincte, complète utilement la signature. Elle précise les préconditions, les effets de bord et les cas d'erreur, informations que le type seul ne transmet pas.
Gérer les erreurs et les ressources de façon explicite
Le Pascal classique ne dispose pas de mécanisme de ramasse-miettes. Chaque allocation doit être libérée, chaque fichier ouvert doit être fermé. Cette contrainte impose une rigueur qui, mal appliquée, produit des fuites mémoire ou des descripteurs épuisés.
Les blocs try…finally permettent de garantir la libération des ressources même en cas d'exception. Leur usage systématique autour de toute acquisition de ressource évite une catégorie entière de bugs. Il reste possible de s'en passer dans du code très local et sans exception, mais cette exception doit être assumée, pas subie.
La gestion des erreurs par codes de retour, fréquente dans le Pascal ancien, coexiste mal avec les exceptions. Une équipe gagne à choisir une convention et à s'y tenir, plutôt qu'à mélanger les deux modèles au fil des fichiers.
Outiller le projet pour rendre les règles vérifiables
Les bonnes pratiques énoncées ci-dessus ne tiennent que si elles sont contrôlées. Le compilateur offre un premier niveau de vérification : activer les avertissements, traiter les avertissements comme des erreurs dans l'intégration continue, refuser les variables non utilisées. Ces réglages sont souvent désactivés par défaut dans les projets anciens.
Quelques règles complémentaires peuvent être vérifiées automatiquement :
- longueur maximale des procédures et des unités ;
- absence de variables globales mutables hors de l'implémentation ;
- présence d'un bloc de libération pour chaque allocation détectable.
Ces contrôles ne remplacent pas la relecture, mais ils éliminent les écarts les plus fréquents. Ils rendent aussi les règles visibles pour les nouveaux arrivants, qui n'ont pas à deviner les conventions à partir du code existant.
Il faut reconnaître une limite : ces pratiques s'appliquent mal à du code généré automatiquement ou à des bibliothèques figées dont la réécriture n'est pas envisageable. Dans ces cas, l'objectif raisonnable est d'isoler ces zones derrière une interface propre, plutôt que de tenter de les normaliser.
