Mono Google Summer of Code
steves
I am a student from Czech Republic, currently studying at Durham
University in England. I am considering participation in GSoC and
Gendarme is among projects that I am interested in. I would prefer the
'writing new rules' part mentioned on Mono student projects proposals
[1], however I am struggling a bit with definition of a moderate rule.
I was thinking of implementing gendarme specific attributes in similar
fashion that findbugs uses java annotations [2], namely following
attributes and corresponding rules:
- CheckReturnValue (the return value of this method should not be
ignored, e.g. string.Substring, int.TryParse, ...)
- OverrideMustInvoke (the override must invoke the base method)
- MustInvoke("MethodName") (for virtual methods: if overridden, it
must invoke some other specific method, e.g. calling Measure in
MeasureOverride in WPF/Silverlight/Moonlight)
- MustBeInvokedAfter("MethodName") (for methods that require some
specific sequence of invocation)
- Other findbug annotations, like NonNull, can be extracted from Code
Contracts. They can be of course checked by cccheck, but in Gendarme
only simple checks without involving the whole machinery of theorem
proving would be performed, meaning that it would be much faster, but
could report more false positives. (I think that this would involve
improving/extending the stack analysis that is already implemented in
Gendarme.)
Aside .NET attributes, it would be convenient to provide some way to
define such annotations for external libraries (e.g., for BCL),
possibly some xml format. Do you think this would be a sensible and
large enough project for GSoC? Any comments would be appreciated.
Steves
[1] http://www.mono-project.com/StudentProjects#Tools_and_Compilers
[2] http://findbugs.sourceforge.net/manual/annotations.html
Sebastien Pouliot
This approach has been tried in the past - but it did not work out and
the rule was eventually removed (the only case). The idea is sound but
it does not mix well with real-life, mostly because:
a. Few people have the time to use tools like Gendarme;
b. Fewer have the time to fix (most of) the defects found;
c. Very few have the time to start instrumenting their code;
d. Even fewer will invest it into application-specific (Gendarme) changes.
Basically (100-a-b-c-d) == 0, not that 'd' is without value - it just
gets multiplied by (near) 0 users.
Now, like I said earlier, the idea is sound and _maybe_ we can try
something like this. However I think it would be best to expand the
potential user base, e.g. by removing 'd'.
Specifically I think the old (removed) rule about (missing) null
checks could be resurrected while using a (subset) of the code
contracts. That could encourage people using code contracts to try
Gendarme (and Gendarme users to try code contracts). In both case half
the investment is already made (and the second half opens much more
future options).
Sebastien
> --
> You received this message because you are subscribed to the Google Groups "Gendarme" group.
> To post to this group, send email to gend...@googlegroups.com.
> To unsubscribe from this group, send email to gendarme+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gendarme?hl=en.
>