[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 =
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,
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
    - 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