extensibility plans (being able to ignore rules)

[shiftkey]

First off, thanks for making this open source. Real easy to use, and my Roslyn-fu is terrible.

I can see some mention of rule types floating around but these don't seem to be used any more. That's fine, I hacked around it for now 😁 and I'm probably missing some context on the decision to drop it.

I wanted to submit some changes that would help my use case, but wanted to see what plans you had (if any) for tailoring CodeFormatter to be able to ignore rules - without turning this into a religious holy war.

The things I had in mind at the moment:

• move FormattingEngine.Create into the main project, so you can include rules from other assemblies outside the core
• an optional list of rules to ignore as the last arguments to CodeFormatter.exe

I don't want to go down the FxCop/StyleCop path of setting up a whole bunch of useless IDs here, or define a "profile-esque" format that you pass in as an argument, so perhaps specifying the type name is okay (and given rules are suffixed with Rule that can be ignored for conciseness). Doing a blacklist rather than whitelist feels more practical because I think you generally want to suppress a couple of rules (that pit of success thing).

So if I wanted to format Octokit I could pass parameters like this to skip the three rules I don't like:

`.\CodeFormatter /nocopyright ExplicitVisibility NewLineAbove PrivateFieldNaming

Or if we want to be more explicit about the intent:

`.\CodeFormatter /nocopyright /skip ExplicitVisibility NewLineAbove PrivateFieldNaming

Thoughts?

[jaredpar]

First sorry for not responding to this sooner. I have my email filters set wrong for this repo and was consequently not getting any updates.

I think this is a great idea and it's something we've heard a few times. It's something we actually need for a couple of our repos (private field renaming for example will break binary serialization). Today I achieve this by ... commenting out the rule and running the formatter. We should really just formalize this in the command line.

[shiftkey]

Today I achieve this by ... commenting out the rule and running the formatter.

Good to know I'm not the only one!

[jaredpar]

Thinking more about this I think we actually want two variants here:

1. Ability to exclude a rule included by default.
2. Ability to include a rule excluded by default.

In general we include all rules by default but there are exceptions. For example today we don't include the readonly rule by default due to some perf concerns. I expect we'll eventually get more of these in the future.

Been mulling over a syntax for supporting both. So far I've come up with the following:

/rule[+|-]:Name1,Name2

Thoughts?

[am11]

👍
IMO, it would probably make sense to use a standard ignore format, which supports glob pattern. This format is implemented by various software:

.gitignore: https://github.com/github/gitignore
.jshintignore: http://jshint.com/docs/cli/
.coffeelintignore: http://www.coffeelint.org/
.weignore: http://vswebessentials.com/features/general#weignore
etc.

In Web Essentials, we used minimatch package (a C# port of node.js minimatch: https://github.com/SLaks/minimatch) to resolve glob patterns for .weignore: https://github.com/madskristensen/WebEssentials2013/pull/1250/files.

[jaredpar]

@am11 I have thought about config file support as well. If we get more granular with the options it would be nice to have a file checked into repos dictating which format they support. I had been thinking about a full config file though vs. an ignore only one.