Does it make a difference if I clean up my uses clause if the removed units are still used in other units?

Question

Personally I like it if my uses clauses are as small as possible, but in many applications the really big units (in terms of bloating the executable) like Forms or VirtualTrees are needed in at least another unit anyway.

So: Does it make a difference if I clean my uses clauses even if in the end no unit is removed from the project? If so: In what way? And: Is cleaning the uses clause something which should be done as soon as possible or can it wait until I find an unused unit by chance?

Answer 1

If it's used elsewhere in the project, it won't make much of a difference, except to produce cleaner code that's easier to read. There are a few minor things it might affect, though.

Compilation order: The compiler decides what order to compile units in based on which units use which units. If you remove a unit from the uses clause of an early unit, that might cause the used unit to be compiled later in the compile cycle. This may not sound like much, but bear in mind that initialization sections run in the same order as the units were compiled. This really shouldn't make much of a difference to your project, though.

CodeInsight: When you pull up the code completion drop-down, it will offer choices based on all the units currently available. You can reduce the number of choices it has to filter through--and thus the amount of time it takes to pull the bloody thing up!--by reducing the number of units you're using. (No, I'm not bitter. Why do you ask?)

Answer 2

Generally no. If a unit is used once, anywhere in the project, it doesn't matter how many more times it's used. Conversely, it doesn't matter how many places you remove a unit from if it's still used at least once somewhere. The compiled program will behave the same, and it will have roughly the same size.

The only difference would be in the order of unit initialization and finalization sections. Unit-usage order affects the order those sections are executed in, although the precise effect has never been documented (so try not to rely on initialization order).

But I still encourage you to clean up your unit lists, for the same reason you're encouraged to clean up your variable lists and your parameter lists. When you get rid of the stuff you don't need, it makes it easier to read the code you've kept because you can be reasonably confident that what you're reading gives an accurate picture of what the code does. If your code mentions a bunch of units but never really makes use of them, then the next time you or someone else looks at the code, there's a good change you're going to spend some time trying to find where your code uses the facilities of those units. (You'll say to yourself, "Hmm, this code includes Graphics, but I can't see where it draws anything. I'd better take another look, because I didn't think this code had any responsibilities like that. Hey, co-worker — can you take some time out of your day to tell me where this unit draws things?")

Answer 3

Use the free Pascal Analyzer to find out unused units in your code.

Answer 4

Yes, there is one trick that is often overlooked and can come bite you in the back:
If there is some initialization/finalization code, it is always executed even when there is no code otherwise called in your unit (and the unit is always included while you'd think it wouldn't). So, removing a unit that you don't need in your project can make a notable difference.

Another thing worth noting is that the order of the units determines which identifier the compiler picks when there are homonyms in 2 different units and you call them without prefixing with the unit name (which you should always do as a best practice).

Other than that, as Mason and Rob pointed out, the units order impacts the order in which they are compiled and the sequence of the initialization/finalization.

As for the code insight, it will be faster if you remove unnecessary units, but also globally if all your units used in the project are explicitly added to the dpr instead of relying on the search path to find them when they are implicitely added through another unit.

Answer 5

I stronlgy disagree with Mason and Rob: it does make a difference!

Dependency reduction.

The difference is not in the current project as explained by Mason and Rob. Instead, the difference is in your NEXT project. If you keep the unnecessary (server) units in your (client) unit, then using that client unit in another project will pull in the dependencies as well. If there are no other justified client units for the units just pulled in, then you have added bloat.