New Rule: AvoidUnsealedUninheritedInternalClassRule

1 view
Skip to first unread message

Scott Peterson

unread,
Feb 4, 2008, 10:02:20 PM2/4/08
to Gendarme
I've added a patch with a new rule to the Files section. The rule will
advise sealing internal classes which are never subclassed.

Sebastien Pouliot

unread,
Feb 5, 2008, 8:47:34 AM2/5/08
to Gendarme
Hello Scott,

On Feb 4, 10:02 pm, Scott Peterson <lunchtimem...@gmail.com> wrote:
> I've added a patch with a new rule to the Files section. The rule will
> advise sealing internal classes which are never subclassed.

Wow, this is a nice morning surprise :) and extra points for the unit
tests!

Even more since I had this in a TomBoy note:
Gendarme.Rules.Performance.SealNonVisibleTypesRule

which was based on an IRC discussion I had with JB a few weeks ago...

<spouliot> jb_: should we have a rule to seal types that are internal
(well not visible) outside an assembly ?
<spouliot> of course only if no other type inherit from it inside the
assembly and, if internal, that the internals are accessible to other
assemblies
<jbe> spouliot, am not sure about your rule to seal internal types
<jbe> but yeah, the more sealed, the better
<spouliot> jbe: somehow it didn't feel totally right, that why I
asked ;-) but I was trying to figure out what problem it could cause
<jbe> I don't think there's any real problem with it
<jbe> but it could be bothering
<jbe> like `I know I'll extend this type at some point`, I don't care
<spouliot> well since it's internal it doesn't break api compatibility
so you can still change it
<spouliot> but I understand it could report a lot of stuff
<jbe> exactly
<jbe> but heh, the more rules the people could pick from, the better
<spouliot> I was enhancing the
ConstructorShouldNotCallVirtualMethodsRule yesterday night and come up
with that, since it wouldn't not report on sealed types
<spouliot> since sealed types are a bit easier to optimize, I guess it
becomes a performance rule :)


While the rule is already useful (enough to be included) the following
would make it even more interesting IMO
<quote>and, if internal, that the internals are accessible to other
assemblies</quote>

This condition, if the assembly is compiled against a runtime >= 2.0,
should not trigger the rule.

Care to add this extra check ? (I think we already have it implemented
in another rule) Also it would be nice to have a bit of documentation
including good and bad examples for the wiki.
http://www.mono-project.com/Gendarme.Rules.Performance

Thanks a lot!
Sebastien

p.s. feel free to surprise me (like this) as often as you want :)
Reply all
Reply to author
Forward
0 new messages