[MonoDevelop] Code analysis soc project

nikhil sarda diff.operator at gmail.com
Fri Apr 2 17:17:26 EDT 2010

I have put up my proposal on google soc app. Feedback is much appreciated!
As per some feedback from Garuma, I will implement the priority queue
using the BlockingCollection.
I am currently working on a more detailed proposal with mockups.
Thanks for your time
Nikhil Sarda

On Sat, Mar 27, 2010 at 2:34 PM, nikhil sarda <diff.operator at gmail.com> wrote:
> Hi,
> I have been working on the basic infrastructure of the code analysis
> project. My idea is to create a system which will allow users to write
> rules in any .Net language of their choice (currently, provided that
> language is C#) to provide for on-the-fly analysis. The way it works
> right now is that I extend TextEditorExtension
> to get the latest parsed document. I then feed this document into the
> analysis engine. This is nothing but a concurrent producer/consumer
> queue. Any rule that is written needs to have certain components
> specified, such as the type of document it operated upon, the
> compilation unit on which it works (for example, method specific rules
> will take as their compilation unit a MethodDeclaration node). These
> rules are required to register with the analysis engine. When a
> document is parsed, an event is raised and the event handler initiates
> a new task. This task is then en-queued in the analysis engine queue.
> A task consists of 3 parts
> 1) A task will first identify which rules registered with the analysis
> engine apply to the current document.
> 2) It then executes the logic of all the rules (can this be done
> concurrently? execution of logic depends on the AST emitted by parser
> service)
> 3) It updates the text editor with respective squiggly lines and icons
> There are now two issues
> 1) En-queuing policy:  If the same file is being edited, then tasks
> will be duplicated. Portions of code that have already been analysed
> will be analysed again unnecessarily. Hence some sort of a policy is
> required for enqueueing of tasks.
> 2) If the ActiveDocument changes, I would like that tasks associated
> with the ActiveDocument should get higher priority. To implement this,
> I could use a priority queue, but theres no such class in the
> Collections framework. One possibility is to use the C5 library.
> I would be grateful for any feedback.
> Thanks
> Nikhil Sarda
> On Fri, Mar 26, 2010 at 9:14 PM, Lluis Sanchez Gual
> <slluis.devel at gmail.com> wrote:
>> All the projects you propose look ok to me. I think the code analysis
>> project is the one that will benefit more users. AFAIR the new DOM is
>> close to be finished, so working on it should be ok. My only concern is
>> that the project may clash with the work mkrueger is doing, so you would
>> need to be in synch with him.
>> El dt 23 de 03 de 2010 a les 01:41 +0530, en/na nikhil sarda va
>> escriure:
>>> Hi,
>>> I am writing this mail to get an opinion on the feasibility of the
>>> on-the-fly code analysis project. This contains information I gleaned
>>> from mhutch and mkrueger in IRC. I had taken the suggestion of mhutch
>>> and was sniffing around the code completion bindings of c# in MD. The
>>> code to underline with red the line of code that is generating a
>>> parser error was straightforward to understand, but trying to
>>> implement some more complicated forms of error detection the way
>>> resharper does is slightly more difficult. Apparently the current
>>> version of NRefactory is not good enough to detect certain types of
>>> semantic errors. Hence detecting errors such as invalid return types,
>>> incorrect parameters and so on are very difficult to do with the
>>> current NRefactory. This is because there is presently no way to go to
>>> the parent of the node you've no way to go to the parent and top-down
>>> analysis is difficult because "<mkrueger>: because you can't go to the
>>> children of the nodes without knowing the type of the node". Some
>>> things that can be implemented however are naming conventions,
>>> spellings in comments and string literals and so on. Given this
>>> backdrop is there any point proceeding with this project? Or should
>>> one wait for the new DOM to be completed?
>>> I had a bunch of other ideas as well that I talked to people about on
>>> IRC and XMPP, but I wanted to get a general opinion as well.
>>> 1) Extending the Code metrics addin: The addin i posted on the mailing
>>> list does quite a few things, but a lot is still left to implement,
>>> such as cohesion, coupling and association between classes. Maybe I
>>> can add a few more metrics such as
>>> http://yunus.hacettepe.edu.tr/~sencer/oom.html
>>> But the killer feature would be CQL, which allows one to query the
>>> code base for types, methods and namespaces that satisfy criteria as
>>> specified in a very SQL type language. NDepend implements CQL and I
>>> will be trying to replicate that.
>>> 2) Allowing for collaborative editing over XMPP, a la google wave.
>>> This will probably require changes to Mono.Texteditor itself
>>> 3) Integration of monodoc (zzz)
>>> Thank you for your time
>>> Nikhil Sarda
>>> _______________________________________________
>>> Monodevelop-list mailing list
>>> Monodevelop-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/monodevelop-list

More information about the Monodevelop-list mailing list