[Monodevelop-devel] Source code analysis and refactoring (GSoC), looking for some clarification.

Michael Hutchinson m.j.hutchinson at gmail.com
Wed Mar 12 03:13:07 UTC 2014

Hi Mark,

Sorry for the late reply, GMail decided to mark this as spam for some
reason known only to itself...

a) Yes, it's a mixture. NRefactory does have systems for defining code
actions and code issues. An IDE (i.e. MD/XS/#D) implements the GUI and
some high-level services needed by the code actions/issues, and
automatically gets all the ones defined in NRefactory. However, there
are some actions/issues/refactorings things that need to implement a
UI, or need access to the project model beyond that available in
NRefactory, and these are implemented in MD/XS. Basically, it would
depend on what exactly you were implementing. Some things could be
done in NR, some could be done in MD, and in some cases it would make
sense to extend the NR abstractions and implement them in MD.

b) This would be another common-sense, case-by-case kind of thing.
Research is great as long as it has some outcome e.g. something like
"I tried implementing the algorithm from this paper but it didn't
perform was well as I hoped" is fine but "I spent a week just reading
papers" probably isn't.

c) code issues and code actions are an unending rabbit hole since
they're about detecting potential problems and improvements in the
code - which to solve perfectly, requires solving the halting problem,
or maybe some kind of strong AI :) Some are almost trivial, e.g. the
existing "extract local from expression", and some are incredibly
complicated, e.g. detecting null dereferences took weeks to implement
and still only handles some locals.

It's all about "bang for the buck". If the code
issue/action/refactoring useful enough assisting users in writing good
code to be worth your time implementing it and the overhead of having
it as part of the IDE?

- M

On 7 March 2014 18:34, garnett m. (mg10g13) <mg10g13 at soton.ac.uk> wrote:
> Hello;
>     I've been around the #monosoc and #monodev channels for a bit now under
> the nick TCD; I was interested in applying for GSoC to work on the source
> code analysis/refactoring area.
> I've talked through it with some people to a degree over IRC, but I've come
> to drafting my proposal and hit some points I wanted to discuss further.
> a) I know that NRefactory is used 'under the hood' for analysis; would
> therefore most work with code actions and refactoring be done within the
> NRefactory project? I noticed there are a lot (a huge amount already) of
> actions in MD, but the only code I could seem to find in the MD base itself
> was for interfacing with code actions.
> b) Would research time - that is, thorough research rather than skimming -
> fall under the GSoC project time, or would it be something to be done prior
> to the project? Obviously work to see what, say, Visual Studio or Eclipse
> provides in the way of code actions would be needed to see what MD is
> lacking.
> c) I'm having some issues with the idea of the scale of the project; on the
> surface, it seems that code actions would not take up much of the 3 months
> of work (unless there were a LOT being added). Would something extra on top
> be expected in a good proposal? I had an idea to add a step-through analyser
> to see and very quickly fix any potential code issues in the selected scope
> (file, project, solution) or some kind of further visualisation of the
> analysis - for instance, providing further detail to the actions listed in
> the menu (what contributes a 'simplify negative relational expression' for
> example?) - but since I wasn't 100% sure of the scale of the project, I
> didn't know whether these would fall under stretch goals if time permits or
> not.
>     Obviously it'd depend on my work speed, but right now when trying to
> sketch out a battleplan I get to 'week 1, detailed research and make sure I
> can work my way around the codebase, week 2+ implement things?' :)
> Thank you for your time,
> Mark/TCD
> _______________________________________________
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list

Michael Hutchinson

More information about the Monodevelop-devel-list mailing list