Add UseConsistentCasing

[Jaykul]

Add lowercase keyword (and operator) enforcement as a separate rule.

I was thinking about adding a check for the correct case of [Types] and [Attribute()]s, but I think that should probably be in the original rule (UseCorrectCasing), which begs the question of whether we should just add that (or all of this) to the existing rule...

Originally, I made a separate rule because I thought I might need to configure the type of case ("lowercase", "UPPERCASE", "CorrectCase") ... but I quickly decided all-caps is awful, and there is no "correct" case (the C# tokenizer code just capitalizes the first letter of each token, and the documentation is inconsistent about capitalization of keywords and operators).

[Jaykul]

Looks like I missed updating some docs/tests

[Jaykul]

Hold off merging this, because I have realized that it does the wrong thing for a few operators.

[rjmholt]

which begs the question of whether we should just add that (or all of this) to the existing rule...

we already have a UseCorrectCasing rule, which is used for cmdlet casing at the moment but I think we could just add CheckOperator and CheckKeyword as options to it and a new option for CheckCmdlet so that user can pick and choose what they prefer

Sorry, I meant to get back to this question earlier.

I think it's better all in one rule, because:

• We have an ongoing problem in PSScriptAnalyzer where rules that do specific things are given general names and then confusingly have competing rules next to them with a name that makes them hard to differentiate
• We also have the opposite problem where some rules have very specific names but philosophically should do more (for example AvoidUsingInvokeExpression should also warn against [scriptblock]::Create() and maybe some other things)
• We have a good story for rule configuration
• In this particular case, I think the desires to case cmdlets and to case keywords/operators correctly are cohesive and really do belong in one rule
• We unfortunately also have a bad story for formatting currently, so piggy-backing on an established formatting rule also provides a workaround there

All the code looks good and looks pretty portable at this stage, so hopefully it's just a case of sticking it inside of some conditional methods in UseCorrectCasing, rejigging the configuration and moving the tests over. But let me know if it's more complicated than that.

[Jaykul]

I'm quite happy to merge them. This was a safer PR just because if you didn't want it, I could take my code and go home 😉

I did add this one to the formatter (you can see in the tests that I verified that worked).

[totkeks]

Any updates on this PR? Would be nice to have this feature in vscode so it autoformats my keywords properly.

[Jaykul]

I quite forgot about it. I'll try to look at it again this week

[PrzemyslawKlys]

Reminder @Jaykul that it's already next week 😂😂

[ykuijs]

Any update on this PR?

[bergmeister]

Last chance @Jaykul as we are starting to wrap up for next release this month

[Jaykul]

It's been a long, long time... There's so much I feel that I should say But words can wait until some other day

[totkeks]

I have seen that this PR has gotten stale a bit again. Is there anything that could be done to help complete it?

I came across this again, because I noticed that I lack an auto-formatter for casing in VS Code for my PowerShell scripts. Which is why it would be really cool to have.