Where do you place your unit uses?

Where do you place your unit uses?

Over the years, I’ve come to preferring to place my uses in the Interface section only, even if its types, constants or methods only are used in the implementation section.

What is your practice, and why do you prefer one pattern over the others – or why would you recommend against one of these patterns?

unit Test;



ThisUnit, ThatUnit;




unit Test;








40 thoughts on “Where do you place your unit uses?

  1. AS. I think units and even in a sense packages are obsolete TP4 remnants. They should have been unified with objects long ago, and ‘uses’ and ‘with’ too.

    Implementation section is analogue of private object section. It is said when introducing new members one should start with private only uplifting them when absolutely necessary. So preventing classes from becoming intertwined and intimately coupled.

    Working with a legacy app, which is IfDef-ridden spaghetti, with same units compiled into different EXEs and DLLs in different subsets, i was taught to appreciate this approach, hard way. Circular references through types and thus units too are so many and deep, there can be no reasonable graph outlined. Splitting logically related functions into many sparcely located units just because “these routines can be compiled into this isolated BPL” does not feel right, but at least is something.

    So, yes, keep as much as you can private(implementation only), as long as you can. For the sake of compatibility and adaptability by loose coupling. And screw DPKs that still so many years later do not have private units!

  2. I am also preferring the second option, as I am with Michael Thuma regarding circular references, too. One major reason for this option in my case: I can see immediately when I can stay in the implementation part when eliminating references or change implementations, while a unit in the interface section signals “You have to change the interface part to get rid of it! This will most likely affect other units, too!”

  3. Just a note: I use the Uses Report in Peganza Pascal Analyzer to identify the candidates for moving to the interface section. The task itself is easily done with Ctrl-Alt-Shift-Up (or Down) from MMX Code Explorer, which moves the unit under the cursor to the other section.

  4. b) of course. To prevent unwanted dependencies between units in the Interface section that someone can accidentally make. If two units have interlinks in the Interface section, it makes sense to think about re-organizing of the code in an application, maybe to merge these units into one. Or to extract the interlinked part to a separate unit.

  5. I put Delphi’s units in the Interface part because they will never use my own code.

    for my own units I put them at the lowest level as possible to avoid circular references

    sometimes, I use a class helper in the implementation part to transtype a member to a specific type instead of placing the unit in the interface part (once again to avoid circular reference)

    unit Unit1;


    TForm1 = class(TForm1)

    procedure Button1Click(Sender: TObject);


    FSomeThing: TObject;






    TForm1Helper = class helper for TForm1

    function SomeThing: TSomething; inline;


    function TForm1Helper.Something: TSomething;


    Result := TSomething(FSomething);


    procedure TForm1.Button1Click(Sender: TObject);




    you can use this to acces to the MainForm from a Frame with TMainForm(Owner) for instance.

    The other option is to add Interfaces

  6. My reason for putting everything in the interface section is that it is, as Dalija Prasnikar points out, the only way to effectively enforce prevention of circular references.

  7. Paul TOTH “I put Delphi’s units in the Interface part because they will never use my own code.”

    Actually you can put them in the Implementation part and they will not use your code too. )

  8. Paul TOTH It’s a different argument. But instead of introducing dependencies into the interface section, we can use GExperts to easily see the used units. Also I’d suggest Thomas Mueller to highlight interlinked units in the lists in the Uses Clause Manager, may be with bold font.

    One more argument against dependencies in the Interface section: when typing in this section, IDE will not display unnecessary autosuggestions (Ctrl-Space), which will also reduce the chance of accidental errors.

  9. I prefer using interface section for all. This way it is easier for me to see what all dependencies are. For my own code this also prevents me from making accidental circular references which usually point to bad design.

    I use implementation section (very rarely) only and only if I have some circular dependencies where getting rid of them would be more trouble than it is worth.

  10. Michael Thuma packages contain units, unit contain types and routines. Both can be seen as namespaces/classes. FPC even has unit global properties.

    From the perspective public contract vs internal implementation details it seems the same

  11. Arioch The Yes, I figured that out. But using implementation section for uses clause can drive you toward such intertwined classes, while using interface section can actively help you to prevent some of those.

    Unless, you are talking about declaring types in implementation section which is completely different topic.

  12. Lars Fosdal Circular references are best avoided by good design. With SOLID development circular unit references should be an extremely rare possibility anyway.

    One other reason for putting units in the implementation section uses clause are that all the ones under your control are in one place for you to manage. The Interface uses clause suffers from Delphi injecting units. Of course sometimes classes are needed in the Interface method declarations leaving you no choice.

  13. Larry Hengen Wouldn’t it be great if we could declare a class in the interface section with only the public and protected members and add the private stuff in an extended declaration in the implementation part?

  14. Uwe Raabe It’s an interesting suggestion…kind if a different take on partial classes. Not sure if that would make it more difficult to understand the class as a whole. Personally I am not the biggest fan of partial classes and extension methods as relevant code in multiple places makes maintenance harder IMHO.

  15. The units in the Interface section are mainly required to satisfy types referenced in the Interface section. I do my best to put units that aren’t required there in the Implementation section.

    I have seen libraries that have minimal units specified in either one, and not even units in the project. Instead, they rely on search paths being set up properly to load up everything implicitly. I do not like this approach at all.

  16. Larry Hengen delphi form designer injects unit ( messing with order and grouping ) in units with, ahem, forms and datamodules.

    There is an opinion, along MVC, that forms should be ends of the design, with all the data classes snd types be in non-visual units. Not that i succeed in this approach myself. But then the units where Delphi does mess would be of little relevance structure-wise and being end leafs would be free from circular dependencies anyway

  17. Joseph Mitzen I think the compiler (with enough smarts) could automatically handle not having two sections, or, alternatively, be able to suggest were what might belong (probably requiring yet another keyword).

  18. I tend to place all uses in the interface section, but some references have to be defined in implementation to avoid circular – which is just the way things are. It would probably be a good feature to remove that old concept, because the parser knows everything after the first pass anyways – so its just an old rule lingering – it havent had any real value after object pascal stopped having a C backend (read: an eternity ago).

  19. If the resource is only used as part of the implementation, I put the uses in the implementation. If it is required as part of the interface definition, I include the unit there. I think its probably from the days when I used Modula-2 with its separate definition and implementation modules. As an aside, I loved Modula-2 at the time I first started using it.

  20. I prefere to place the unit where it is required. A part of hidding the implementation if you prefer. By choosing carefully the scope it’s easier to track down used units and replacing them without harming the code. In fact I try to avoid placing unit in the interface. I like my units as:

    unit MyTest;



    TMyClass = Class



    uses Sysutils;

    {… some code requiring sysutis ..}

    This way I know exactly what is required to “interface” with that class.

  21. Mike Versteeg As John Lennon once coded….

    Imagine there’s no interface section

    It’s easy if you try

    No implementation section below it

    But it would still be Delphi

    Imagine all the people

    Not telling unit users what they can’t do….

    Imagine there’s no initialization section

    It isn’t hard to do

    Sections come from COBOL

    Circa 1962

    Imagine all the people

    using units with nothing to hide….

    You may say I’m a dreamer

    But I’m not the only one

    They hide nothing in Python

    and IEEE Spectrum ranks it number one

    Imagine not using properties

    For every dang integer and real

    If you’re not assigning methods

    I don’t get it; what’s the deal?

    Imagine all the people

    Embracing YAGNI….

    You may say I’m a dreamer

    But I’m not the only one

    I hope someday we’ll see

    A Delphi compiler with passes more than one

    Imagine no hidden classes

    I know marc hoffman thinks that’s heresy

    He must have added 17 class modifers to Oxygene

    Including “Not_Even_Howard_Carter_Could_Unseal_Me”

    Imagine RemObjects

    Letting all the classes be free…

    Imagine class methods

    Not being separated from their definition

    You may think separation is better

    I think that’s just superstition

    Imagine knowing how a class works

    Without hitting page-down, page-down, page-down….

    You may say I’m a dreamer

    But I’m not the only one any more

    marc hoffman made this possible

    In Oxygene 8.4….

  22. If a unit exports nothing that could be required in interface sections of other units I would prefer to always use the unit in implementation sections. If a unit exports something that could be required in interface sections of other units (types, constants) I would prefer to always use the unit in interface sections.

    And I never write circular dependent units.

  23. Lars Fosdal Basically, yes. On the other hand, if I recall what has happened to a couple of other addons acquired and then orphaned, I am pretty fine with the current situation.