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.