[MonoDevelop] Code analysis soc project

[Mike Krüger]

Hi

> That's great to hear!
> 
> I'm a huge fan of the idea of on-the-fly analysis.
> 
> As I see it, the core part is a framework for background analysers -
> an extension point, a service to run the analysers on new
> ParsedDocuments and report the errors and warnings, and some basic
> configuration UI. This is the initial "barrier" that needs to be
> implemented before anyone can write any analysis rules. This could
> take quite a few weeks to fully implement and polish.  It would also
> be nice to have a way for rules to attach "fixes" to their results,
> and this would need a UI too. All of this is completely language
> agnostic. For example, I might want to write analysers for ASP.NET
> documents or XML, not just C#.
> 
> Beyond that, there are analysis rules, that scan the parsed documents
> and report errors, warnings and suggestions. These rules can range
> from trivial to very complex, and some are much more useful than
> others.
> 
> My favourite example of a rule is an API naming conventions checker.
> This would check that any public symbols defined in the file follow
> .NET naming conventions, e.g. interfaces begin with I, class and
> member names are PascalCase, parameters are camelCase, and all
> identifiers are made of CorrectlySpelledWords. This rule would work
> for any parsed .NET DOM, not just C#, and would be great for teaching
> the conventions to newcomers, but also to catch typos from seasoned
> users. It could easily offer quick fixes too, as these would just be
> rename refactorings. In fact, quite a few of the framework design
> guideline rules could be checked in a language-agnostic way with the
> current DOM, since they affect only public API.
> 

Maybe re-implementing all gendarme rules using the ParsedDocument ? 
(including gendarme >may< be easier - hey gendarme developers: include
gendarme - this way more people will use it)

> Another idea is to show unresolved types and unused usings. This would
> be C#-only, and require attempting to resolve all types, and could
> offer the existing "resolve" command as a quick fix. Other easy yet
> useful rules would be to warn about recursion in properties, error on
> trivial (i.e. clearly infinite) property recursion, warn about catch
> blocks that completely discard the exception, check that string.Format
> format is correct, warn about string concatenation in a loop...
> 
> Of course there are *many* more complex rules that could be
> implemented, but are beyond the scope of a single GSoC project. The
> main thing would be to get the framework implemented and polished,
> with some fairly simple yet very useful rules to prove it, which would
> make it possible for other people to contribute individual rules
> afterwards.
>
> (I didn't mention spellchecking strings and comments because I think
> that *might* be better for the text editor to handle based on syntax
> highlighting, as it would work for many more filetypes. But
> specialized rules could do a better job because they'd have more
> context).
> 

The spellechecking should be done with red underlines ... the other
things are more complex. For example the unused usings/unresolved types
could be 'grayed out' by the C# syntax highlighting. More serve 'bugs'
may generate warnings or even errors for the task list. 

btw. doing this with the current NRefactory AST isn't easy/doable. I've
run into NRefactory AST problems while doing refactorings ... and I only
did very simple AST analyzation.

Regards
Mike