lint for D

Nick Sabalausky a at a.a
Thu Jul 10 12:56:12 PDT 2008


"Robert Fraser" <fraserofthenight at gmail.com> wrote in message 
news:g55p65$1pga$1 at digitalmars.com...
> 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.

Good point. In which case, I still say a command-line version is essential, 
but it could happily co-exist with a more integrated IDE version (and maybe 
use a common library). 





More information about the Digitalmars-d mailing list