Feature ideas - MaxWarnings and AutoLowerMaxWarnings

[mcintyre321]

Hi, I have an idea for a couple of new settings which would be a big help when introducing NsDepCop into legacy projects.

Right now, if I were to add NsDepCop to a legacy project at work, there would be lots of violations as the layering isn't correct. This makes it hard to bring in as I can't set NsDepCop to raise errors (there are too many to fix) and if I set it to warning mode, then other developers will ignore the violations.

I was thinking that a new rule attribute MaxWarnings could be added that would throw an error if there are more than a certain number of warnings would be very useful. I could set it to the current number of violations and ensure that no new (or at least no more) violations are added, so the codebase wouldn't get any worse.

Another setting could then be AutoLowerMaxWarnings. This would change the MaxWarnings value in the config file to the current number of violations IF the current number is less than MaxWarnings. This would mean that developers could reduce the number of violations, but they couldn't increase them.

These settings could work both at an individual rule level, or for all rules.

What do you think? It would be great to have these features on the roadmap. If you like the sound of them, then I could maybe take a look when I get a chance*.

*I have a baby arriving in the next 3-4 weeks so it might be a while though!

[realvizu]

Thanks for the suggestions! Making it easier to start using the tool in a legacy codebase sounds like a relevant scenario and should be supported. However, relying on issue count seems a bit fuzzy.
Let me try to come up with an alternative suggestion to reach the same goal.

How about specifying areas of the codebase to be temporarily excluded from analysis? E.g. defining source file include/exclude lists (with wildcards)? So those files that contain unresolved dependency problems could be excluded; or the other way around: including only those files that were "cleaned". This way the config file could explicitly reflect the problem areas (or clean areas) instead of just holding some magic number of tolerated issues.

What do you think? Would it be a solution in your case?

And best wishes for you and the arriving baby!
Have plenty of sleep while you can ;)

[mcintyre321]

Thanks for the advice :)

I'm going to have to stick up for MaxWarnings!

I've worked somewhere where we used a MaxWarnings approach to successfully reduce StyleCop errors from 100000+ to ~1000 over a period of months. It 'nudged' the team into adopting the standards, but gave them a little flexibility if they needed it (e.g. they could manually increase the count if it became necessary in order to meet delivery targets).

In many of the organisations where I think NsDepCop would be most useful, spending time enforcing layering isn't a priority (devs have to deliver features, architects are more worried about establishing boundaries via microservices). I suspect having fine-grained control over the exclusions would mean that no-one would spend the time necessary to configure them correctly. The rules that are needed are along the lines of <Disallow From="*.Domain" To="*.DataAccess" />.

[realvizu]

Okay, I've created a milestone to address this (v1.8).

[mcintyre321]

Awesome!

[realvizu]

Please see:
https://www.nuget.org/packages/NsDepCop/1.8.0-beta1