The latest question about use clause cleaners, got me thinking: How important is such a tool, given the linker should automatically remove everything that isn't referenced. So, how much harm does an unused unit actually do? A former colleague of mine routinely added a standard list of units to the interface of every unit he created. It annoyed the hell out of me when I discovered it, since most of them could at least be moved to the implementation section.
The latest question about use clause cleaners, got me thinking: How important is such a tool, given the linker should automatically remove everything that isn't referenced. So, how much harm does an unused unit actually do? A former colleague of mine routinely added a standard list of units to the interface of every unit he created. It annoyed the hell out of me when I discovered it, since most of them could at least be moved to the implementation section.
On the other hand, we have several programs where the unit's initialisation code registers classes, object instances or functions with a factory or other mechanism, so removing them from the uses clause would break the functionality.
On the other hand, we have several programs where the unit's initialisation code registers classes, object instances or functions with a factory or other mechanism, so removing them from the uses clause would break the functionality.
I'd like to know that too. Does this have real impact on something? It's like the unused local variables, right?
ReplyDeletePerfectionism is the key. Purism too, may be. But, the feedback of see a perfect code, has no price!
ReplyDeleteIt's not a joke. I'm sure that this may be an important reason for some of us.
No more, but sufficient.
We can't be sure that in future versions of the product it continues not being necessary a clean up in the "use" clauses.
As well as, a bad formated code compiles perfectly, but his maintenance is complex, a "use" clause clean is more easy to understand than a "use" clause over populated and full of not used units.
With enhanced RTTI, how can the linker do that? It cannot know whether or not something will be used.
ReplyDeleteAnd any automatic cleaner can't deal with initialization code.
It does have an impact. Any units that has initialisation /finalisation routines will pull what it needs in, no matter if the unit is used or not. Of course if the unit is used elsewhere in the project, the init/final sections will be pulled in anyway
ReplyDeleteWe have built our own Uses Cleaner, which translates all the points mentioned. The reason was that studies have shown that the compiler seeks all units that are referenced, regardless of whether they are needed or not. Since our project currently has 30000 units (20M Loc), compile times beyond the 45 minutes were the rule. With the IdeFixPacks from Andreas (he cough the search calls) and the Uses Cleaner, we are now on 6 minutes.
ReplyDeleteI tend to mark units solely used for initialisation sections or inline optimisations as such in the uses clause.
ReplyDeleteIn that sense, I'd like a uses list cleaner to be able to mark potential units that might not be needed as such, not blindly remove them.
A unit may have had another added to its uses clause at one stage, but is subsequently not required. Consider the scenario where the used unit has an initialization
ReplyDeletesection that does something otherwise undesirable, or perhaps might have one added sometime down the track? I'd want to be able to identify that kind of unit for potential removal.
I would put it in the same box as code that can never be executed (like if then). Besides that it detracts you it also suggests dependencies that simply don't exist.
ReplyDeleteRecently I had a unit that had a bunch of VCL units in its uses clause. After removing those actually never used the unit was perfectly qualified as platform independent.
Roland Wind Is your uses cleaner publicly avaiable? If not, are you planning to do so? That's an impressive time saving!
ReplyDeleteMoving units from interface to implementaation can reduce compilation time.
ReplyDeleteAlexander Sviridenkov
ReplyDeleteThis can be a very good an important functionality of a "Use clause cleaner" program.
It must be capable of suggest, or in fact do it, the units that are better placed at implementation section than interface section.
Alexander Sviridenkov Why is that?
ReplyDeleteDavid Heffernan I think you will get less cyclic behaviour in the compiler.
ReplyDeleteWhat the cleaner tak-ith away - F12+FS may put-ith back in (so help us GOD).
ReplyDeleteDavid Heffernan don't know exactly, but I saw comments where moving units to implementation leads to 3-5 times faster compilation on big project.
ReplyDelete+Alexander is right. We tend to do this in our Development Cycle.
ReplyDeleteOur Uses Cleaner is part of our Experts. It works after each Compile Cycle and Checks which File was changed (Subversion Modified File). The Uses Clause of every changed file will be analyzed and the Units which are not necessary will be removed. After this the Compiler run will be executed programmatically again (if the User wants this) to check, if the Uses Cleaner did not remove to much.
ReplyDeleteWe use this since 6 Years and it works fine.
Attila Kovacs you've not encountered enough lazy Delphi programmers yet.
ReplyDeleteJeroen Wiert Pluimers Attila Kovacs I tend to place my imports in the interface uses if I am importing units that are of a lower level than the using unit. Doing so reinforces the hierarchy to the reader of the code.
ReplyDeleteDavid Heffernan structured approaches always win.
ReplyDeletemoving "uses" from the interface section to "implementation" section also reduces the chance of getting the circular reference errors.
ReplyDelete/sub
ReplyDeleteRoland Wind The list of repositories in your account on GitHub is impressive. Employees of our company also make efforts to improve the process of continuous integration. We try to adopt the best technologies, study modern trends in development and automation of processes. Removing from the list of unused modules in Delphi projects we perform using CNPack uses cleaner or manually. I would also like to try alternative options that will lead to better results.
ReplyDeleteJudging by your words, the expert written by you works perfectly and does not cause any complaints. I would also like to embed a similar mechanism in our Compile Cycle at the moment when the file was changed (Subversion Modified File). Can you share this technology, publish your expert in the form in which it is? Accordingly, we are ready to independently correct some parts of the code to bring the plug to an operational state within our environment, if required.