Skip to content

Conversation

@Managor
Copy link
Member

@Managor Managor commented Dec 6, 2025

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.

@github-actions github-actions bot added the documentation Issues/PRs modifying the documentation. label Dec 6, 2025
@Managor Managor requested a review from waldyrious December 6, 2025 22:10
@waldyrious
Copy link
Member

The Special Cases category is starting to feel a bit bloated.

Totally agreed.

If anyone wants, they can take similar instructions and put them under their own category.

I had actually started working on precisely that change :) hopefully I can submit it after this change gets in.


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`.
Copy link
Member

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?

Suggested change
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`.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Issues/PRs modifying the documentation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants