Pourquoi spécifier les noms de modules
Dans l'article précédente "Crack C# namespaces in 30 secondes" je vous ai montré comment tomber sur une erreur en C# sans la savoir et donc passer les heures après sur la débogage. Mais en C# vous êtes condamnés à utiliser la directive using
sinon le code devient illisible rapidement avec tout ces MySolution.AppModules.Accounting.AccountingType.DefaultValue
.
En Delphi et Free Pascal vous n'êtes pas obligés de spécifier le nom d'unité, mais cette pratique vous préviendra des erreur de genre décrit dans l'article.
Voici une exemple simple.
Le programme principale:
program Print; uses Orders; begin writeln('Order default state is ', DefaultState); end.
La constante est définie dans l'unité Orders:
unit Orders; interface const DefaultState = 'submitted'; implementation end.
Si on lance, le résultat est attendu :
Order default state is submitted
Un jour vous avez besoin d'utiliser certains fonction de module Calculs.
unit Calculs; interface const DefaultState = 10234; implementation end.
Dans le programme on rajoute ce module :
uses Orders, Calculs;
On relance et voila une mauvaise surprise...
Order default state is 10234
La correction est évidente :
writeln('Order default state is ', Orders.DefaultState);
Conclusions
- Spécifier le nom d'unité pour les constants, fonctions et même les types publiques est un bonne pratique qui vous protège des erreurs de ce genre
- L'ordonnance des modules dans
uses
est important. C'est pourquoi il est recommandé de les spécifier à partir des modules plus basiques de run-time (SysUtils, Classes...), puis OS-specific (Windows, Unix...), puis framework-specific (VCL et Co) et enfin vos unités applicatives.