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.

[bergmeister]

Thanks for the effort, looks ok from a high level.
But 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. Keeping it in one rule will make things easier to integrate the new settings into the VS-Code extension, which already has scaffolding for UseCorrectCasing. Also, if you wanted the rule to be usable by the formatter and the vs-code extension, you'd have to register it here.
WDYT @rjmholt

[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.