[Monodevelop-devel] GSoC Source Analysis

Luís Reis luiscubal at gmail.com
Thu Apr 25 22:02:19 UTC 2013


Hello,

I've looked at the project ideas page to help me decide which
proposal(s) to make and the "Source Analysis" idea caught my
attention.

If I understand this correctly, it's about checking for code issues
and offering the option to correct them.
This project reminds me of Gendarme, although Gendarme runs on
compiled executables/libraries and does not offer the option to fix
the code automatically.
Is that the sort of issues you wish to see the source analysis check for?

One thing I noticed is that (git master) MonoDevelop has a
"MonoDevelop.CSharp.Refactoring.CodeIssues.NamingInspection"
interface, but I don't see any warnings in the editor. Am I looking at
the wrong place? Am I doing something wrong?

If I was assigned to this project, I'd start with something simple
like directly extracting a lambda expression to a method (which
currently requires two steps), and then advance for more complex
stuff.
The possibilities include:

1. Check for switch statements on enums that do not include a default
case/are missing cases
2. Check for unused exceptions (equivalent of
CheckNewExceptionWithoutThrowingRule in Gendarme, but with the option
to fix it by adding a 'throw')
3. If a class has a public method with no arguments named 'Dispose'
but does not implement IDisposable, show a warning (similar to
OnlyUseDisposeForIDisposableTypesRule in Gendarme) and show the option
to fix by adding IDisposable to list of implemented interfaces.
4. Option to convert query syntax LINQ expression to the equivalent
method syntax.
For instance, "from x in y select x + 1" would become "y.Select(x => x + 1)"
Also, the reverse operation could be available.
5. (No warning - just an available refactoring action) Convert if or
?: expression to ??, if applicable.
6. DoNotLockOnThisOrTypesRule equivalent - option to create a private
mutex object
7. Same for DoNotUseMethodImplOptionsSynchronizedRule.
8. DoNotUseThreadStaticWithInstanceFieldsRule - option to either
remove the attribute or make field static
9. Option to remove (or add) redundant access modifiers (such as
private for class fields)
10. Option to remove unused private fields or methods
11. Equivalent of DoNotDestroyStackTraceRule and option to fix
12. XamarinStudio bug #10351 https://bugzilla.xamarin.com/show_bug.cgi?id=10351

I'm not sure how long each of these tasks take (since I'm not yet very
familiar with the MonoDevelop code), so I'd like some feedback to know
not only if this is what's intended, but also how many of these tasks
should be done (are these too many? too few? just enough?)
I know C# (it's currently one of my most frequently used
languages),but not NRefactory (so I don't yet know how hard these
tasks are nor how long they should take)

By the way, I've noticed a bug in MonoDevelop (git master) while I was
using the current refactoring tools:
When I have this code:
var y = (Func<int, int>)(x => x);
"Convert to anonymous delegate" generates this (incorrect) code:
var y = (Func<int, int>)(delegate (int x) {
    x;
});
Note the lack of a return statement.
(I guess fixing this rule could be a good starting point to learn how
things are currently done if it isn't fixed until the project starts.)

Thank you for your time,
Luís Reis


More information about the Monodevelop-devel-list mailing list