-
-
Notifications
You must be signed in to change notification settings - Fork 5k
style-guide: add file extension instructions #19776
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
base: main
Are you sure you want to change the base?
Conversation
Totally agreed.
I had actually started working on precisely that change :) hopefully I can submit it after this change gets in. |
contributing-guides/style-guide.md
Outdated
|
|
||
| Whereas for Powershell, prepend the environment variable with a dollar sign, Env and a colon, then enclose it with backticks (`$Env:VARIABLE_NAME`). For example: "Manage the `$Env:JAVA_HOME` environment variable". | ||
|
|
||
| When describing file formats, either use the brand name like JSON, or prepend the file extensions with a dot like `.warts`. |
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.
The "warts" example might be a little obscure. What about using an example that's both more well-known as a file extension, and looks more like a brand name in plain text?
| When describing file formats, either use the brand name like JSON, or prepend the file extensions with a dot like `.warts`. | |
| When describing file formats, either use the brand name like JavaScript, or use a file extension with a dot like `.js`. |
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.
It's not written anywhere, but we tend to always prefer brand names over technical terms. Having these be the same would go against that.
I chose .warts only because I like to use examples where the guideline was discovered. We can change that to something else.
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.
we tend to always prefer brand names over technical terms. Having these be the same would go against that.
I'm not sure I follow. Are you saying that the guideline you're adding currently says "Do X or Y", but you think it should imply "...but preferably X"?
It's not written anywhere
Indeed, why not just say it explicitly, then? I don't think having Y refer to a different entity than X implies that we have a preference for X's form.
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.
I'll make changes.
The Special Cases category is starting to feel a bit bloated. If anyone wants, they can take similar instructions and put them under their own category.