Jump to content
Jacek Laskowski

Unused local variables

Recommended Posts

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.

Share this post


Link to post
Posted (edited)

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

 

btw. copy paste into a text file and grep

Edited by Attila Kovacs
  • Like 1

Share this post


Link to post
Posted (edited)

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 by dummzeuch
  • Like 2

Share this post


Link to post

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.

 

 

Share this post


Link to post
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.

  • Like 3

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

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"

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

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....

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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!)

  • Like 2
  • Thanks 1

Share this post


Link to post
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?

Share this post


Link to post
Posted (edited)
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 by Stefan Glienke

Share this post


Link to post
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...

Share this post


Link to post
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...

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)
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 by Stregor

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×