DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe

[bearophile]

Andrei Alexandrescu:

> Youtube: http://youtube.com/watch?v=ph_uU7_QGY0

It's an interesting talk. Maybe all talks of this conference were 
interesting.

Some notes on the slides.

- - - - - - - - - - - -

Slide 12:

>A class is an item with a strict boundary. e.g.: Arrays will be 
>dupped at these borders.<

I think this kind of privacy for reference data is a common need. 
I think enforcing this is not a job of static analysis tools, it 
looks like a job for the type system. An annotation should 
suffice (in theory this annotation should allow the access of the 
array from outside, so it should be forbidden by default for 
private fields. Now this can't be done, so an annotation needs to 
do the opposite). Maybe this needs some discussion in the main D 
newsgroup.

- - - - - - - - - - - -

Slide 12:

>We do not use Ddoc, because most important information about 
>functions are not included.
- In- / Out-Constrains
- Exceptional Cases aka Throws<

How to annotate throws in ddoct? Do they need to be generated 
automatically?

Regarding pre/post conditions, maybe a ddoc macro or switch can 
be used to make them appear in the ddoc output on request.

- - - - - - - - - - - -

Slide 12:

>Next to classes also model package dependency
- no cyclic dependencies anymore<

Maybe it's possisible to add some way (like a standard 
annotation) to enforce the absence of cyclic dependencies in a 
section of a project (like inside a package).

- - - - - - - - - - - -

Slide 14:

>- Private static functions which could be tested inplace are 
>tested using D-unittest-Blocks (Unit =:= Function)
- Other tests require setups, teardowns, names (Testdox 
http://agiledox.sourceforge.net/). Need to be filtered, selected. 
For them using Dunit. (Unit =:= Class / Struct)<

I think the built-in unit test system should be improved, so in 
_most_ cases there's no need to use a second unittest system.

Bye,
bearophile