On The Design Of Uses Clauses

[Uwe Raabe 2064]

While working on a tool for cleaning up uses clauses I stumbled upon this beast (slightly changed to protect the innocent):

{$if defined(DEBUG) or defined(DEBUG_SPECIAL)}
uses
{$ifend}
{$IFDEF DEBUG}
  dialogs
{$ENDIF}
//<some comment about the following ifdef>
{$IFDEF DEBUG_SPECIAL}
  mmsystem, // timeGetTime()
  messages
{$ENDIF}
{$if defined(DEBUG) or defined(DEBUG_SPECIAL)}
  ;
{$ifend} 

If you are only looking for uses clauses inside some Delphi sources and try to avoid a full featured parser, you will have a pretty hard job to detect, parse and interpret that one correctly.

 

So, if you are interested to make any use of such a tool, please do me a favor: Don't write your code that way! It is hard to read for humans anyway.

[valex 0]

A good tool must handle comments and conditionals correctly IMHO.

But it'll not be easy.

[Uwe Raabe 2064]

Well, the actual problem here are the conditionals around the uses keyword and the closing semicolon. The rest inside is fine.

 

This version is handled without problems:

{$if defined(DEBUG) or defined(DEBUG_SPECIAL)}
uses
{$IFDEF DEBUG}
  dialogs
{$ENDIF}
//<some comment about the following ifdef>
{$IFDEF DEBUG_SPECIAL}
  mmsystem, // timeGetTime()
  messages
{$ENDIF}
  ;
{$ifend} 

 

[Fritzew 51]

Yes this look like a nightmare, if you want to parse the source and not only create a AST

[Bill Meyer 337]

3 hours ago, Uwe Raabe said:

Well, the actual problem here are the conditionals around the uses keyword and the closing semicolon. The rest inside is fine.

 

This version is handled without problems:

{$if defined(DEBUG) or defined(DEBUG_SPECIAL)}
uses
{$IFDEF DEBUG}
  dialogs
{$ENDIF}
//<some comment about the following ifdef>
{$IFDEF DEBUG_SPECIAL}
  mmsystem, // timeGetTime()
  messages
{$ENDIF}
  ;
{$ifend} 

 

I have been pondering the problem myself, as I want to reorder the uses clauses in a large number of units. The variations imposed over the years by thoughtless developers make the task a good deal more challenging than it ought to be:

uses

  OneUnit, Another, MyThird

, Fourth, {NoLongerUsed,} 

StillMore {Why here?}, 

Last

;

 

Conditionals obviously add to the fun. Moreover, I want to organize so that Delphi library modules are in the first grouping, then third-party, and last, units of the application. And then, of course, to provide for walking the file tree and applying changes to each application module found in the map file. 

[Uwe Raabe 2064]

1 hour ago, Bill Meyer said:

Moreover, I want to organize so that Delphi library modules are in the first grouping, then third-party, and last, units of the application. And then, of course, to provide for walking the file tree and applying changes to each application module found in the map file. 

Are you interested to do some testing?

[Bill Meyer 337]

10 minutes ago, Uwe Raabe said:

Are you interested to do some testing?

Yes, I could do that. I assume, however, that you are implementing for v14, not for earlier versions? Most of my work is in D2007, where I have literally thousands of such uses clauses to work with. 

[Uwe Raabe 2064]

1 hour ago, Bill Meyer said:

I assume, however, that you are implementing for v14, not for earlier versions? Most of my work is in D2007

I am referring to a command line tool.

[Bill Meyer 337]

3 minutes ago, Uwe Raabe said:

I am referring to a command line tool.

Well, that would be very interesting. I would be happy to do some testing.

[Fr0sT.Brutal 900]

On 7/18/2019 at 9:44 PM, Bill Meyer said:

Moreover, I want to organize so that Delphi library modules are in the first grouping, then third-party, and last, units of the application. And then, of course, to provide for walking the file tree and applying changes to each application module found in the map file. 

That's exactly the scheme I came to. I also avoid using units in impl. section except for app's forms.

[Bill Meyer 337]

4 hours ago, Fr0sT.Brutal said:

That's exactly the scheme I came to. I also avoid using units in impl. section except for app's forms.

Actually, I find it is better to add references in the implementation section, if they are not needed in the interface. Unit dependency cycles should always be avoided, but there are tools which can help you with that (MMX, Delphi Unit Dependency Scanner), and the need for such cycles is always indicative of design problems. 

In general, keep scope everywhere as narrow as possible.

[Uwe Raabe 2064]

16 minutes ago, Bill Meyer said:

In general, keep scope everywhere as narrow as possible.

Amen!

[Mike Torrettinni 198]

On 7/18/2019 at 2:44 PM, Bill Meyer said:

I have been pondering the problem myself, as I want to reorder the uses clauses in a large number of units. The variations imposed over the years by thoughtless developers make the task a good deal more challenging than it ought to be:

uses

  OneUnit, Another, MyThird

, Fourth, {NoLongerUsed,} 

StillMore {Why here?}, 

Last

;

 

What is the purpose of keeping {NoLongerUsed,} in the uses clause? If it compiles, it can be removed, right?

 

Also on StillMore {Why here?}, ... why would there be such indication? If it doesn't compile without StillMore then it should be there, no?

 

I don't understand these concepts, I only set those units in uses clause that need to be there. I follow compiler and hints what needs to be there. If it compiles without units, I don't put them there.

[Bill Meyer 337]

9 minutes ago, Mike Torrettinni said:

What is the purpose of keeping {NoLongerUsed,} in the uses clause? If it compiles, it can be removed, right?

 

Also on StillMore {Why here?}, ... why would there be such indication? If it doesn't compile without StillMore then it should be there, no?

 

I don't understand these concepts, I only set those units in uses clause that need to be there. I follow compiler and hints what needs to be there. If it compiles without units, I don't put them there.

Legacy code is its own excuse. Whatever the reasons may have been, these are examples which exist now, and which I need to parse out without damage to the rest. With over 2,000 units to process, and most containing uses clauses in both interface and implementation, the why of what is there is not my concern. Cleaning is my focus. And NOT by hand.

[Mike Torrettinni 198]

7 minutes ago, Bill Meyer said:

Legacy code is its own excuse. Whatever the reasons may have been, these are examples which exist now, and which I need to parse out without damage to the rest. With over 2,000 units to process, and most containing uses clauses in both interface and implementation, the why of what is there is not my concern. Cleaning is my focus. And NOT by hand.

I don't envy you, at all. I'm cleaning up my own code and it takes a lot for each unit, form, especially if redesign is needed. The easiest is decoupling forms, but some redesigns take time, too much time.

[Bill Meyer 337]

50 minutes ago, Mike Torrettinni said:

I don't envy you, at all. I'm cleaning up my own code and it takes a lot for each unit, form, especially if redesign is needed. The easiest is decoupling forms, but some redesigns take time, too much time.

It's not always fun. 😉 But it is a continuing challenge.

[sLesage 0]

On 7/18/2019 at 8:44 PM, Bill Meyer said:

I have been pondering the problem myself, as I want to reorder the uses clauses in a large number of units. The variations imposed over the years by thoughtless developers make the task a good deal more challenging than it ought to be:

uses

I've actually been using a similar approach too. But as a Delphi Consultant I've seen very strange things already ... The order of the Uses clause might actually be important especially when some variables or other things get set up in the Initialisation section of a unit. Oh and @Uwe Raabe any news on the tool ? Been searching for a good tool which can detect unused units / restructure uses clauses for a while now.,

[Uwe Raabe 2064]

@sLesage

This is an early beta. It is a command line tool called with the following parameters:

UsesCleaner [<filepath>]<filename> [-c:<configfile>] [-o:<outputpath>] [-l:<logfile>] [-s]

<filename> may contain wildcards
<configfile> default is UsesCleaner.cfg
<outputpath> if not specified, original files will be changed!
-s: also handles subfolders

 

The example config file is targeting Delphi 10.2 Tokyo, but can easily be adjusted. Some entries are self-explaining.

[Settings]
Indentation=2
Compressed=1
MaxLineLength=130
SearchPath=c:\program files (x86)\embarcadero\studio\19.0\lib\Win32\release;
UnitAliases=WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;
UnitScopeNames=Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;System;Xml;Data;Datasnap;Bde;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell
GroupNames=@DelphiOTA;Winapi;System.Win;System;Data;FireDAC;Vcl;Rz*

[Groups]
DelphiOTA=ToolsAPI;DesignIntf;DesignEditors

The tool will resolve any unit aliases and unit scope names. Then it will group the units according to the order given in GroupNames followed by any remaining units. Plain group names are taken as namespace prefix (like Data or Vcl). Unit names without such namespace can be grouped with wildcards (like Rz* for Raize Components units). You can define groups by simply listing the unit names in the Groups section as it is show with the DelphiOTA group.

UsesCleaner.zip

[sLesage 0]

This looks interesting ... Some Suggestions / Ideas :

 

• Option to put every unit on it's own line
• Option to put an empty line in between groups

I will give it a few more spins on bigger projects to see if everything works OK.

[sLesage 0]

I like this ... This in combination with a remove unused units would be heaven for me ... Well maybe a remove unused unit which would also move uses from Interface to Implementation if they aren't needed in the interface section 🙂

 

what does the Compressed setting in the Config file do ? Havn't been able to make it do anything ... or I don't know what it does.

[Bill Meyer 337]

3 hours ago, sLesage said:

I've actually been using a similar approach too. But as a Delphi Consultant I've seen very strange things already ... The order of the Uses clause might actually be important especially when some variables or other things get set up in the Initialisation section of a unit. Oh and @Uwe Raabe any news on the tool ? Been searching for a good tool which can detect unused units / restructure uses clauses for a while now.,

I solved the initialization issue by logging to find the order in which the initialization clauses were fired, then replaced initialization and finalization with procedures which are called from my own initialization unit.

 

Still much work to be done on the uses cleanup, and the untangling of dependency cycles, but I no longer have to worry over initialization stability.

Edited August 23, 2019 by Bill Meyer

[Uwe Raabe 2064]

1 hour ago, sLesage said:

Option to put every unit on it's own line

Set Compressed=0

 

55 minutes ago, sLesage said:

what does the Compressed setting in the Config file do ? Havn't been able to make it do anything ... or I don't know what it does.

See above.

[Uwe Raabe 2064]

1 hour ago, sLesage said:

This in combination with a remove unused units would be heaven for me ... Well maybe a remove unused unit which would also move uses from Interface to Implementation if they aren't needed in the interface section

Well, that would require some sort of compilation or so and is definitely outside the scope of such a tool.

 

It might be worth to investigate in interpreting the output of Peganza Pascal Analyzer Uses Report and act accordingly. This would eliminate the burden of analyzing the code.

[sLesage 0]

Well ... I actually though I had tried that but with Compressed=1 becuase I thought it would put 1 uses on every line. But now I get it ... it's just a boolean, nut the number of units on a line. Loving it already ... Currently I have this approach but might be fooling around with the groups.

 

[Settings]
Indentation=2
Compressed=0
MaxLineLength=80
SearchPath=c:\program files (x86)\embarcadero\studio\19.0\lib\Win32\release;
UnitAliases=WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;
UnitScopeNames=Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;System;Xml;Data;Datasnap;Bde;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell
GroupNames=@DelphiOTA;Winapi;System.Win;System;Data;FireDAC;Datasnap;REST;Vcl;cx*;dx*

[Groups]
DelphiOTA=ToolsAPI;DesignIntf;DesignEditors

Oh ... and I know I'm exagerating here ... but an option to add the GroupNames as a comment line before the first Uses ? And maybe an option to add a blank line between every group of uses ? I know I'm probably one of the very few peeps who does it like that, so no worries if it isn't possible.

[Bill Meyer 337]

18 minutes ago, Uwe Raabe said:

It might be worth to investigate in interpreting the output of Peganza Pascal Analyzer Uses Report and act accordingly. This would eliminate the burden of analyzing the code.

I can attest that the Peganza Pascal Analyzer Lite Uses Report has been very helpful. Note, however, that it is by no means perfect.

1. It seems always to report falsely that a class helper unit is not needed.

2. It tends to suggest removing units which are actually needed.

3. It sometimes asserts a unit ref can be in implementation, when the IDE wants to replace it in interface.

4. Form inheritance complicates the issues.

 

That said, it is the only tool I am aware of which provides assistance in finding which unit refs can be demoted to implementation.

 

For removal of unused units, I prefer CnPack, which does a test compile, and works with the map file, I believe.