lint for D

[Nick Sabalausky]

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