>From my experience I've seen that lint tools are very useful to quickly find >many bugs, on the other hand most of my friends don't use them. This is a >problem I've felt for some time. Recently I have found an interesting paper >that expresses my feelings better:
"Condate: A Proto-language at the Confluence Between Checking and Compiling" by Nic Volanschi http://mygcc.free.fr/condate-ppdp06.pdf A quote from the first part of the paper: > Existing tools use various approaches, but share a common, apparently minor design choice: they are specialized tools, doing only program checking. There are several important drawbacks of this design: - most of the tools are completely decoupled from existing development environments - they duplicate a considerable amount of work on program parsing and program analysis; this is true even for tools that achieve a superficial level of integration by being called automatically from existing IDEs or makefiles - they afford to perform costly analyses, which make them unsuitable for daily use throughout development; at best, existing tools aim only at scalable analyses - last but not least, many programmers completely ignore their existence. As a consequence of these and maybe other reasons, for instance related to usability or to limited distribution policies (some proprietary tools being kept as a competitive advantage), checking tools are not used on a large scale nowadays. To solve the above design-related issues, we propose to integrate some amount of user-defined checking within the core of every development process -- the compiler. < All this is related to the "mygcc" that's the kind of plug-in for GCC I have talked about recently. It uses a half a page of rules to find lot of bugs in C code. I don't know if similar rules may be written to catch bugs in D code too, because the bugs are often of different kind (and maybe less simple). If you want more info about Condate: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.69.2171 Bye, bearophile
