Unused local variables

[Jacek Laskowski 57]

Is there any tool that can scan the project and show unused local variables?

 

I know that the compiler shows it, but it is not very clear in the log filled with various warnings.

[Attila Kovacs 629]

Why would you bother some unused variables if you can live with those warnings?

 

btw. copy paste into a text file and grep

Edited March 19, 2019 by Attila Kovacs

[dummzeuch 1505]

What do you mean by "log filled with various warnings"? Do you really have more than a hand full?

That's the first thing I kick a coworker's ass for, if it gehts checked in to SCM.

 

OK, a possible solution would be to configure these hints / warnings you are really interested into be errors in the project configuration -> Building -> Delphi Compiler -> Hints and Warnings.

 

edit: Apparently that's not possible for hints but only for warnings.

Edited March 19, 2019 by dummzeuch

[Jacek Laskowski 57]

I knew that you're sticking to it ... 🙂
I try to eliminate warnings from my own code, but I have warnings from external libraries, eg Synapse, DCPCrypt and others.

 

 

[dummzeuch 1505]

1 minute ago, Jacek Laskowski said:

I knew that you're sticking to it ... 🙂
I try to eliminate warnings from my own code, but I have warnings from external libraries, eg Synapse, DCPCrypt and others.

Kick those lazy bastards into the ass! 😉

 

As a workaround you could add a {$warnings off} and {$hints off} into theses 3rd party units.

[PeterBelow 238]

1 hour ago, Jacek Laskowski said:

I knew that you're sticking to it ... 🙂
I try to eliminate warnings from my own code, but I have warnings from external libraries, eg Synapse, DCPCrypt and others.

 

 

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

[dummzeuch 1505]

3 hours ago, PeterBelow said:

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

I always build 3rd party sources with the project. That's the only way I can be sure that the executable is based on the code it is supposed to be. And since compile times in Delphi are really short, it doesn't have any drawbacks in my opinion.

[Stefan Glienke 2002]

That's why Peter said prebuild - you do that once (and whenever you need to fix some of 3rd party code which is compared to your own code rather rare talking from experience) and then use the produced dcus. That way you only get compiler messages from your code without being mixed with any 3rd party noise.

 

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue. Especially when Delphi decided that it does not like the "compile" option for whatever reasons and forces you to do "build"

[Bill Meyer 337]

20 minutes ago, Stefan Glienke said:

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue. Especially when Delphi decided that it does not like the "compile" option for whatever reasons and forces you to do "build"

It's been a very long time since I trusted much in the "compile" option. I don't recall (later than Delphi 1) that it ever felt very reliable.

[MSGEndoDoc 0]

Returning to the unused local variables issue.  Have found that Lazarus 1.8 has a great feature of underlining any unused local variables in the method's declaration section so you dont have to searc through the messages log.  Would be great if Delphi did this too - well after they fix the squiggly red line problem....

[dummzeuch 1505]

There would be quite a lot of useful things that could be done if there was an up to date parser for Delphi code. Unfortunately there apparently isn't.

I tried to update Martin Waldenburg's parser, which is used in GExperts, but it's just not easy to do. The Castalia parser, which is based on MW's parser unfortunately is incompatible in too many places to use as a replacement without too many changes. But by the look of it, it supports more recent language constructs. It's still not complete though, and definitely doesn't support the latest additions.

[Sherlock 663]

Please, don't waste energy on reinventing the wheel. The hint H2164 is there and even if I rebuild 3rd party every time I still see hints and warnings coming from my code.

[jeroenp 26]

The best open source Delphi parser I know is DelphiAST. It is the foundation https://www.tmssoftware.com/site/fixinsight.asp which catches way more code issues than the Delphi compiler itself does.

 

DelphiAST gets you an abstract syntax tree. Code is at https://github.com/RomanYankovsky/DelphiAST

[Guest]

17 minutes ago, dummzeuch said:

There would be quite a lot of useful things that could be done if there was an up to date parser for Delphi code.

Maybe in the (very far) future Emba will release an open source compiler* like Roslyn so we can forget all other parsers. Until that time we have to live with all that Error Insight crap.

 

* Don‘t get me wrong: It is only the compiler, not RTL or any other Framework source.

[Stefan Glienke 2002]

1 hour ago, dummzeuch said:

I tried to update Martin Waldenburg's parser, which is used in GExperts, but it's just not easy to do. The Castalia parser, which is based on MW's parser unfortunately is incompatible in too many places to use as a replacement without too many changes. But by the look of it, it supports more recent language constructs. It's still not complete though, and definitely doesn't support the latest additions.

As Jeroen already mentioned: use DelphiAST - that is based on the Castalia parser code which was based on Martin Waldenburgs code. It is used and maintained by the author of FixInsight and many others and can handle any Delphi code out there. It had a lot of fixes due to it being used in FixInsight which is widely used by numerous people. It even supports inline variables (hello Error Insight!)

[Attila Kovacs 629]

@Stefan Glienke off> btw, regarding to DelphiAST updates, are you planning to update your uses helper? </off

[dummzeuch 1505]

17 hours ago, Stefan Glienke said:

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue.

What do you consider a "large enough application" in this context?

[Stefan Glienke 2002]

4 minutes ago, dummzeuch said:

What do you consider a "large enough application" in this context?

Large enough that you don't want to rebuild third party code every time you hit F9+something or waste minutes on the CI server

Edited March 20, 2019 by Stefan Glienke

[dummzeuch 1505]

1 hour ago, Stefan Glienke said:

Large enough that you don't want to rebuild third party code every time you hit F9+something or waste minutes on the CI server

Ok, so the applications I am working on are far from being "large enough" then. A full build of even the largest one takes about 10 seconds on my computer, only compiling is only marginally faster.

On the CI server it takes longer to update the source code than to build the applications.

 

And I thought these applications were already large...

[Sherlock 663]

37 minutes ago, dummzeuch said:

And I thought these applications were already large...

Thank you! I thought I was the only one with "small" applications. My main application only has 18.000 LOC client side and roughly 5000 LOC server side. And its a medical device developed for cross platform use...

[dummzeuch 1505]

28 minutes ago, Sherlock said:

Thank you! I thought I was the only one with "small" applications. My main application only has 18.000 LOC client side and roughly 5000 LOC server side. And its a medical device developed for cross platform use...

It's difficult to say how many LOC "my" application has, because as I said I always compile 3rd party libs / components. With that, the largest one (I think) builds 1.843 million lines of code, another one gets to 1.074 million LOC. But since I have no idea how much of that is 3rd party stuff (JCL, JVCL, TeeChart, FastReport, ccpack, ccrexif, tComport, DSpack, DSPmaster, dxgettext, gdiplus, GraphicEx, graphics32, Indy10, jedimath,mtxvec, nativeexcel, synedit, tdbf, tregexpr, VirtualTreeView), I can't really say how much of that is our own code.

A complete build with Delphi 2007 of the largest one takes about 25 seconds on my computer.

Hm, I think that's getting rather off topic now.

[Bill Meyer 337]

1 hour ago, dummzeuch said:

And I thought these applications were already large...

Large is not only lines of code. It also encompasses legacy code with pervasive unit dependency cycles. Then we are talking minutes to build. Yes, minutes.

[Georgge Bakh 29]

I-Pascal highlights unused local identifiers in real time.

Whole project can be inspected as well by "Analyze->Inspect Code..." menu option.

It really can save some time preventing bugs getting into the code on early stage.

So I think this is a must have feature for a modern IDE.

[Stregor 0]

On 3/19/2019 at 3:19 PM, PeterBelow said:

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

 

On 3/19/2019 at 8:22 PM, Stefan Glienke said:

That's why Peter said prebuild - you do that once (and whenever you need to fix some of 3rd party code which is compared to your own code rather rare talking from experience) and then use the produced dcus. That way you only get compiler messages from your code without being mixed with any 3rd party noise.

 

If you work on a large enough application with enough developers that produce builds nonstop rebuilding the same unchanged source code every time is an issue. Especially when Delphi decided that it does not like the "compile" option for whatever reasons and forces you to do "build"

 

I have problem with that.

I create small test project, one form with one visual component. Visual component is a part of, for example, devex library.

I want to not recompile devex every time I must build project, so:

1) I build my project once,

2) I copied devex .dcu from project output dir to a separate directory (for example "builded_dcu")

3) I remove path to devex source files from Library path and put it to Browse path

4) I put path to "builded_dcu" folder to Delphi Library path.

 

And...

 

If I compile, it's work. Delphi use ""builded_dcu" as source of Devex .dcu, compile only my own code, everything is ok. But when I build my project, Delphi want access to .dfm and .res files from Devex source.

 

What i do wrong?

 

I must build my own code, because i use simultaneously 2 or more build configurations with different conditional defines with my own code.

 

Workaround will be put in Library path first path to "builded_dcu", then path to Devex source, but when I build, I build all, my own code and Devex code. I must copy every single .dfm and .res from Devex to "builded_dcu" folder? Or is a other way, and I do some terrible mistake?

Edited April 9, 2019 by Stregor

[Uwe Raabe 2057]

21 minutes ago, Stregor said:

Delphi want access to .dfm and .res files

That is why those files have to be copied into the builded_dcu folder. You can see the same issue with the standard library folders of the Delphi DCUs. The DFM and RES files can also be found there.