Gendarme.Framework.Rocks
Sebastien Pouliot
Following (but not totally blindly ;-) JB Evain, of Cecil-fame, newest
project Mono.Rocks [1] and some discussions at the last Mono summit,
Gendarme's first rocks are now in SVN (and some people, besides me,
already started using them!).
The main goals are to
* reduce code duplication: giving us smaller rules, which will be
easier to read, review and understand
* have a better tested framework: each rocks must come with it's own
unit tests
* have better documentation: each rocks must come with it's own
documentation
The only thing to watch for (an old saying of mine) is to avoid
creating rocks, or any code, that isn't immediately useful (e.g.
because we want to do x, y or z in the future). So please find a nice
*and* virtual window before throwing any rock (and never throw them at
a gendarme ;-)
Notes
* the Mono.Rocks google group [2] contains more advice on how to
create rocks.
* it's also possible to cherry-pick some rocks from Mono.Rocks and
copy-paste[3] them inside Gendarme.Framework.
[1] http://www.mono-project.com/Rocks
[2] http://groups.google.com/group/mono-rocks
[3] at this, still early, stage Gendarme won't add a dependency on
Mono.Rocks. However this could change in the future, so keeping all of
them inside their own namepace(s) will make the job easier.
This is probably my last post for 2007, so Happy New Year to everyone!
Sebastien
Néstor Salceda
On jue, 2007-12-27 at 17:43 -0800, Sebastien Pouliot wrote:
> Hello everyone,
Hello Sebastien.
> Following (but not totally blindly ;-) JB Evain, of Cecil-fame, newest
> project Mono.Rocks [1] and some discussions at the last Mono summit,
> Gendarme's first rocks are now in SVN (and some people, besides me,
> already started using them!).
>
> The main goals are to
>
> * reduce code duplication: giving us smaller rules, which will be
> easier to read, review and understand
Yes, in this case IMHO the size matters. I have seen your new rules
(AvoidEmptyInterfaces, AvoidPropertiesWithoutGetAccessor ...) and I like
the new code.
> * have a better tested framework: each rocks must come with it's own
> unit tests
>
> * have better documentation: each rocks must come with it's own
> documentation
This could be linked with the monodoc task, and I have seen you write
comments in the code with <summary> and <params> and other tags. Then I
will try to import those comments to the monodoc documentation.
> The only thing to watch for (an old saying of mine) is to avoid
> creating rocks, or any code, that isn't immediately useful (e.g.
> because we want to do x, y or z in the future). So please find a nice
> *and* virtual window before throwing any rock (and never throw them at
> a gendarme ;-)
I usually follow an heuristic for this kind of stuff, for example; if I
need only a time some feature for a rule (IsCompilerGenerated) then I
write it in the rule, but if I'm writting a new rule and I need that
feature, then the code could be placed into the rock and refactor the
old code.
> [3] at this, still early, stage Gendarme won't add a dependency on
> Mono.Rocks. However this could change in the future, so keeping all of
> them inside their own namepace(s) will make the job easier.
Yes, I agree.
> This is probably my last post for 2007, so Happy New Year to everyone!
Same for you Sebastien (and everyone), Happy New Year. Nice work ! :)
Néstor.
Sebastien Pouliot
On Dec 28, 7:31 am, Néstor Salceda <nestor.salc...@gmail.com> wrote:
> On jue, 2007-12-27 at 17:43 -0800, Sebastien Pouliot wrote:
> > * have better documentation: each rocks must come with it's own
> > documentation
>
> This could be linked with the monodoc task, and I have seen you write
> comments in the code with <summary> and <params> and other tags. Then I
> will try to import those comments to the monodoc documentation.
MonoDevelop to write/test rules.
> > The only thing to watch for (an old saying of mine) is to avoid
> > creating rocks, or any code, that isn't immediately useful (e.g.
> > because we want to do x, y or z in the future). So please find a nice
> > *and* virtual window before throwing any rock (and never throw them at
> > a gendarme ;-)
>
> I usually follow an heuristic for this kind of stuff, for example; if I
> need only a time some feature for a rule (IsCompilerGenerated) then I
> write it in the rule, but if I'm writting a new rule and I need that
> feature, then the code could be placed into the rock and refactor the
> old code.
looking, with good reasons I admit, for symmetry ;-)
E.g. providing IsGetter without IsSetter would be "bad" (even if only
one was needed at the time).
Thanks for the feedback!
Sebastien (still in 2007)
Néstor Salceda
On vie, 2007-12-28 at 08:44 -0800, Sebastien Pouliot wrote:
> Hola Nestor!
>
> On Dec 28, 7:31 am, Néstor Salceda <nestor.salc...@gmail.com> wrote:
> > On jue, 2007-12-27 at 17:43 -0800, Sebastien Pouliot wrote:
> > > * have better documentation: each rocks must come with it's own
> > > documentation
> >
> > This could be linked with the monodoc task, and I have seen you write
> > comments in the code with <summary> and <params> and other tags. Then I
> > will try to import those comments to the monodoc documentation.
>
> That would be very nice :) and make it easier for people using
> MonoDevelop to write/test rules.
I got a preview patch :) Apply it and type make doc. This will
generate a new directory called doc, and then you could see the
documentation typing: monodoc --edit doc
With the patch we will regenerate completely the documentation, not
updates it or anything else.
> > > The only thing to watch for (an old saying of mine) is to avoid
> > > creating rocks, or any code, that isn't immediately useful (e.g.
> > > because we want to do x, y or z in the future). So please find a nice
> > > *and* virtual window before throwing any rock (and never throw them at
> > > a gendarme ;-)
> >
> > I usually follow an heuristic for this kind of stuff, for example; if I
> > need only a time some feature for a rule (IsCompilerGenerated) then I
> > write it in the rule, but if I'm writting a new rule and I need that
> > feature, then the code could be placed into the rock and refactor the
> > old code.
>
> Yes, this is probably the best way to do it - except JB will be
> looking, with good reasons I admit, for symmetry ;-)
> E.g. providing IsGetter without IsSetter would be "bad" (even if only
> one was needed at the time).
Yes, in this case, I also understand and share the reason for the
symmetry :)
> Thanks for the feedback!
Néstor.