-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add UseConsistentCasing #1704
base: main
Are you sure you want to change the base?
Add UseConsistentCasing #1704
Conversation
Looks like I missed updating some docs/tests |
c9fe6ea
to
df1e30d
Compare
Hold off merging this, because I have realized that it does the wrong thing for a few operators. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Sorry, I meant to get back to this question earlier. I think it's better all in one rule, because:
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 |
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). |
Any updates on this PR? Would be nice to have this feature in vscode so it autoformats my keywords properly. |
I quite forgot about it. I'll try to look at it again this week |
Reminder @Jaykul that it's already next week 😂😂 |
Any update on this PR? |
Last chance @Jaykul as we are starting to wrap up for next release this month |
522aa79
to
7525ff1
Compare
It's been a long, long time... |
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. |
Ping? |
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).