Tips from the compiler

Nick Sabalausky a at a.a
Mon Oct 18 01:44:30 PDT 2010


"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.686.1287379375.858.digitalmars-d at puremagic.com...
> On Sunday 17 October 2010 22:00:34 Nick Sabalausky wrote:
>> > And honestly, I think that things like dangling else, unused variables,
>> > and
>> > redundant code make a lot more sense it a tool that is looking for
>> > potential
>> > programming errors rather than the compiler. It's the compiler's job to
>> > correctly generate the code that it's given, not worry about all of the
>> > possible
>> > ways that the programmer could have screwed up when they wrote the 
>> > code.
>> >
>> > - Jonathan M Davis
>>
>> The problem I've always seen with lint tools is you have two choices: A.
>> Run them occasionally, or B. Set up the build system to run them on every
>> compile. So:
>>
>> If you do A, you minimize the usefulness because you're not informed of
>> potential issues until likely well after they've been introduced into the
>> code.
>>
>> If you do B, then you may as well just have them built right into the
>> compiler. And, in fact, outside of planet Mars, that's what's done: We 
>> call
>> them "warnings".
>
> The problem is that there are a lot of things that you can warn about 
> which
> aren't necessarily a problem, and it can be really annoying to have to fix 
> a
> bunch of useless warnings.

Yea, maybe I oversimplified (I was in a hurry), but there are a lot of 
things out there that just simply don't fit into the "ok"/"bad" dichotomy. 
Fortunately, that's already been solved with multiple warning levels:

- Errors: For things that are just plain wrong: Always on, fatal.

- Warnings A: For things that are likely problems, but are acceptable 
temporarily (and only temporarily), ie, until you're ready to make a commit: 
Always on, nonfatal.

- Warnings B: For things that may indicate a problem (and therefore are 
useful to be notified of), but may also be perfectly correct: Normally off, 
but occasionally turn on to check.

- Warnings C: For things that may indicate a problem, but take a significant 
amount of processing time: Normally off, but occasionally turn on to check, 
possibly as a background cron job.

Often, lint tools are used to handle "B" and "C". But, and this is my other 
point, it's not as if there're really any difference between (pure examples, 
not proposed syntax):

> dlint --pedantic foo.d    # <-- "B"
vs
> dmd --pedantic foo.d    # <-- "B"

or:

> dlint --deep-analysis foo.d    # <-- "C"
vs
> dmd --deep-analysis foo.d    # <-- "C"

But then, I've never really been one to buy into any of those unixy "purity" 
ideals.




More information about the Digitalmars-d mailing list