I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching "Exception", and a few other things.

There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with?

It would be perfect have plugin for any Text Editor like Sublime

On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote:
> I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching "Exception", and a few other things.
>
> There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with?

I don't have any D specific errors that I keep repeating. I use SonarQube at work with Java. Here is a list of some of the "rules" that I use:
https://github.com/SonarSource/sonar-java/tree/master/java-checks/src/main/java/org/sonar/java/checks

On 1/20/2014 8:34 PM, Brian Schott wrote:
> I've checked in code to the DScanner project that gives it some basic static
> analysis capabilities. When run with the --styleCheck option, it will warn about
> a few things like empty declarations, implicit string concatenation, classes
> with lowercase_names, catching "Exception", and a few other things.
>
> There's a small feature wishlist in the project's README, but I'd like to get
> some opinions from the newsgroup: What kinds of errors have you seen in your
> code that you think a static analysis tool could help with?

Automated source code formatting would be nice (and it's not as easy as it looks).

On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote:
> Automated source code formatting would be nice (and it's not as easy as it looks).

It has nothing to do with static analysis.

On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote:
> I've checked in code to the DScanner project that gives it some basic static analysis capabilities. When run with the --styleCheck option, it will warn about a few things like empty declarations, implicit string concatenation, classes with lowercase_names, catching "Exception", and a few other things.
>
> There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with?

I'd personally love to see most of existing DMD warnings moved to DScanner and, after it get some recognition, removed from compiler completely. That, of course, implies some way to tune output for specific project, supressing some of detection patterns.

That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally?

On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote:
> That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally?

I assume you're talking about something like @SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html

On 1/21/2014 12:54 AM, Dicebot wrote:
> On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote:
>> Automated source code formatting would be nice (and it's not as easy as it
>> looks).
>
> It has nothing to do with static analysis.

Coverity (a static analyzer) does checks based on whitespace indentation. It's not a great leap from there to just format it.

On Tuesday, 21 January 2014 at 09:11:37 UTC, Brian Schott wrote:
> On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote:
>> That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally?
>
> I assume you're talking about something like @SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html

I was thinking of a more fine-tuned thing, similar to gcc `__attribute__ (unused)` but generalised a bit to not interfere with normal attributes by using reserved namespace.

Single @SuppressWarnings (analysis reports in our case) can be a simpler compromise though.

On Tuesday, 21 January 2014 at 09:22:16 UTC, Walter Bright wrote:
> Coverity (a static analyzer) does checks based on whitespace indentation. It's not a great leap from there to just format it.

One can also say that it is not a huge leap for compiler to do the same. Of course all those tool can share a lot of implementation and often are used together, but I think there is a value in keeping unrelated functionality separately available. UNIX-way ftw.