[MonoDevelop] Code analysis soc project

[nikhil sarda]

Hi,

On Wed, Mar 24, 2010 at 12:36 PM, Mike Krüger <mkrueger at novell.com> wrote:
> Hi
>
>> That's great to hear!
>>
>> I'm a huge fan of the idea of on-the-fly analysis.

Do I earn brownie points if I make this my soc? :)

>> 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#.

What I thought was that the code analysis addin could be run in a
separate thread. It will periodically check the state of the project
and if it finds that documents
have been changed it will reconstruct the AST using the parser service
and feed it to the analysis engine. The engine will then run all the
valid rules on the parser units on another thread and then update the
editor accordingly. A time lag is inevitable, and obviously an initial
implementation will lag for very large code bases.

I have become quite familiar with the new DOM. I have partially
implemented a rule for CS5001 (source file must have Main) and
checking functions for invalid returns  http://pastebin.com/zPnNwvs3
Again these are POCs, I had to do an ugly hack to workaround the non
availability of getting the ReturnType of a method. There are similar
problems getting their arguments as well.

>> 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.

I was thinking of implementing some of the rules as defined here
http://msdn.microsoft.com/en-us/library/ms228296%28VS.80%29.aspx

>> 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.
>>

Won't this be a bit difficult (impossible?) to implement? I mean, how
can I tokenize Correct lySpel ledWords ? Will some sort of a
dictionary need to be incorporated?

> 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...

Many of these rules can be implemented quite straightforwardly if I
have the corresponding parse units.
For unresolved types and unused variables in classes and methods, I
will probably have to save it in some sort of a dictionary to store
and verify at each ExpressionStatement, VariableDeclaration, etc
whether or not they have been used. Ditto for methods, I will have to
create a dictionary first and then verify if they appear anywhere in
various InvocationExpression. Also note that this is a solution wide
rule. MHutch pointed out that I should focus on rules valid for
individual files for now, which is what I plan on doing.

>> 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
>
>

The new DOM is quite familiar to me now. I think this would be a good
project because not only will it allow me to create a useful tool, but
it can provide a good test case and feedback regarding the new DOM.
Also, I plan to refactor the metrics addin to use the new DOM as soon
as it becomes 100% stable.

Regards
Nikhil Sarda