lint for D

[Robert Fraser]

Nick Sabalausky Wrote:

> "Ary Borenszweig" <ary at esperanto.org.ar> wrote in message 
> news:g54po3$2s7h$1 at digitalmars.com...
> > Bruce Adams a écrit :
> >> On Thu, 10 Jul 2008 02:44:07 +0100, Ary Borenszweig 
> >> <ary at esperanto.org.ar> wrote:
> >>
> >>> Bruce Adams a écrit :
> >>>>  Hi all,
> >>>>        Alas this is not an announcement. It should be relatively easy 
> >>>> to knock up a few noddy scripts that can detect some kinds
> >>>> of potential problem.
> >>>
> >>> It should be relatively easy to write a plugin for Descent to do that. 
> >>> Something similar to FindBugs for Java ( 
> >>> http://findbugs.sourceforge.net/ ). Given a source file, you can ask 
> >>> Descent for it's AST with complete type resolution. You can apply the 
> >>> visitor pattern, which is supported by the AST nodes. You can store in a 
> >>> list which variables are declared, and then if they are used in a 
> >>> function or are written too, you eliminate them. The remaining entries 
> >>> in the list are the unused variables. It's a little harder for 
> >>> class/struct members, but it's still relatively easy.
> >>>
> >>> It is both helpful for a developer and for Descent, because the code 
> >>> that support that is kind of finished, but it isn't tested much (it's 
> >>> only used in highlighting code, which seems to work fine). Of course I 
> >>> could do that, but atm I'm adding support for D2, plus it would be 
> >>> interesting if anyone else could join the project.
> >>
> >> This is a pet hate of mine. Tool should not be plug-ins for IDEs.
> >
> > The thing is, you write all the code, then, from time to time you run that 
> > lint tool. You get 200 warnings. Will you want to correct them? Come on, 
> > those are just warnings, and 200 of them! Maybe there's no time, maybe it 
> > doesn't worth the effort. And you'd have to open up the code, remember 
> > what it was about, understanding it...
> >
> 
> Problem goes away with a thing called discipline. It's been about 10 years 
> since I've allowed my warning counts to get anywhere near that big, and even 
> if it did suddenly happen to me today, there's not a chance I'd allow myself 
> to be intimidated by it.
> 
> > In an IDE: you finish writing a method. Even while writing at it, you get 
> > the warnings. It's easy to correct, you are there, staring at the code. It 
> > won't take your time, you have the code in your head, you know why the 
> > warning is there and how to remove it. And you do it.
> >
> 
> I agree a tool like this should be integrated/integratable into an IDE. BUT, 
> there should at least be a command-line version so that you aren't married 
> to a specific IDE (or any IDE at all if you happen to be that kind of 
> person). I think the eclipse plugin that was proposed sounds great *as a 
> start* because, from the sound of it (I wouldn't know, I don't like to use 
> Eclipse) it would allow *something* to be out there much more quickly than 
> starting a new command-line tool and getting it up to speed. Maybe it could 
> even be used for prototyping diagnostic ideas. BUT, I would consider a 
> command-line version (even if it were built into the compiler - though I'm 
> sure that won't ever happen) to be essential, and something to eventually 
> replace (or at least exist side-by-side) the interim Eclipse-based solution.
> 
> > Just my thought...

What Ary was saying is that an IDE tool can do the checks while you type.
A command-line tool can't do that. And wrapping a GUI around a different
process is a non-trivial task.

Both tool types have their uses in different situations.