Loading...

gendarme@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

[gendarme] Re: Solution attribute change proposal Cedric Vivier Tue Feb 10 22:00:44 2009

Oh btw, I've had a pending draft with a slight refinement of the idea (just
rename Risk by something else ;) :


On Wed, Jan 21, 2009 at 10:38 AM, Cedric Vivier <[EMAIL PROTECTED]> wrote:

>
> [Solution ("Remove the unneeded finalizer from this type to reduce the GC
> work.", Risk.None)]
> class RemoveUnneededFinalizerRule...
>


Maybe it makes sense to add a Risk.Unknown so that rules with a currently
no-parameter [Solution] can work as-is.
Risk.Unknown would be the default if no Risk is specified in [Solution].

Also, for some rules, it probably makes sense to be able to specify a
different risk according to the target visibility.
This would result into this 'api':

[AttributeUsage (AttributeTargets.Class, AllowMultiple = true, Inherited =
true)]
sealed public class SolutionAttribute {
public SolutionAttribute(string solution)
public SolutionAttribute(string solution, Risk risk)
public SolutionAttribute(string solution, Risk risk, Risk internalRisk)

public string Solution {...}

public Risk Risk {...}

public bool HasInternalRisk {...}
public Risk InternalRisk {...}
}


So that, for such rules, the runner can appropriately use the risk that is
related to the visibility of the target, such as:

[Solution ("Replace the method by an event.", Risk.High, Risk.Low)]
[Solution ("Rename the method to something less confusing.", Risk.High,
Risk.Low)]
public class PreferEventsOverMethodsRule : Rule, IMethodRule {



To assess the risk consistently a simple set of guidelines could be :

- assume the user applied solution correctly (ie. no typo, no logic bug,
change made throughout the declaring assembly of the target if needed [e.g
renaming used method],..).

- think for both internal (declaring assembly) and external (referencing the
declaring assembly) how the behavior could change *directly right after the
change:
    - breakage possibly cannot occur => Risk.None
    - breakage might occur if non-resilient reflection logic is present (e.g
GetType..) => Risk.Low
    - breakage might occur at compile-time => Risk.Medium
    - breakage might occur _fast_ at run-time (ie. assembly loading /
initial startup) => Risk.High
    - breakage might be noticed by testing only => Risk.Critical

- if both risks are the same, do not specify an internal risk.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Gendarme" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/gendarme?hl=en
-~----------~----~----~----~------~----~------~--~---