lint for D

[Bruce Adams]

On Thu, 10 Jul 2008 06:28:59 +0100, Markus Koskimies  
<markus at reaaliaika.net> wrote:

> I have followed a little bit about conversation of D compiler warnings
> and such, and I know that there are people who think that these kinds of
> things should go to another tool.
>
> I must disagree with this. Just like D has integrated doc generator, I
> would like to see it bundled with a tool doing all kinds of static checks
> also; it need not to be integral inside, but released with compiler and
> automatically invoked by the compiler. The reason for this hope is very
> simple - it would make things simple from developers point of view. Just
> write:
>
> 	dmd <all my D files>
>
> ...And it would not only compile the executable (possible recognizing
> which files need to be recompiled, normally done by make), but also run
> static checker. That's also the reason why I like the "-od" -style
> options (telling directories to put things).

I am in the camp that would have more warnings in dmd too but I can't see  
that
happening. gcc is an example of both the good and bad of this. It has  
10,000
options making it non trivial to understand the API let alone test it.
The options have to reworked for each
target OS by configure command otherwise treat warnings as errors makes  
code
fail to compile. The warnings changing with each version of gcc is a bit  
like
minor language specification changes (as Walter noted).

With all the warnings switched on your need for a lint is vastly reduced.
I a have so far unable to convince my workplace of the need for lint  
because
we use gcc and it has a lot of warnings. I believe the gain from lint is  
still
significant but its harder to demonstrate.

 From what I hear about ddoc it is vastly inferior to Doxygen (speaking as  
usual from ignorance).
Doxygen is a dedicated documentation tool so its good at that one thing.
For dmd the compilation side is most important and ddoc is probably not  
even third fiddle.
Doxygen also has the benefit of being language independent.
You have to actively choose to use it though.
There is a lot of benefit to be had from the community making  
recommendations for
preferred tools rather than proliferating. In the case of thing you  
integrate into your
build process at least. This is not true for IDEs (which are more  
subjective anyway).

>
> I know that the UNIX way of thinking is to put everything in to separate
> programs, but that was just my thought.

It is and it isn't. Anyway you can still have one program as the driver
that invokes multiple programs. gcc does this under the bonnet.

Regards,

Bruce.