Skip to content

Commit

Permalink
Remove "singular forms"
Browse files Browse the repository at this point in the history
We don't agree on this particular point, as we have been using plurals
almost everywhere. There are also some subtle complexities with what the
specific guidelines might be.
  • Loading branch information
ehuss committed Oct 3, 2024
1 parent 3c7523f commit 0ab2181
Showing 1 changed file with 0 additions and 1 deletion.
1 change: 0 additions & 1 deletion docs/authoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,6 @@ When assigning rules to new paragraphs, or when modifying rule names, use the fo
* If the rule is naming a specific Rust language construct (e.g. an attribute, standard library type/function, or keyword-introduced concept), use the construct as named in the language, appropriately case-adjusted (but do not replace `_`s with `-`s).
* Other than Rust language concepts with `_`s in the name, use `-` characters to separate words within a "subrule".
* Whenever possible, do not repeat previous components of the rule.
* Prefer using singular forms of words over plural unless the rule applies to a list or the construct is named as plural in the language (e.g. `r[attribute.diagnostic.lint.group]).
* Edition differences admonitions should typically be named by the edition referenced directly by the rule. If multiple editions are named, use the one for which the behavior is defined by the admonition, and not by a previous paragraph.
* Target specific admonitions should typically be named by the least specific target property to which they apply (e.g. if a rule affects all x86 CPUs, the rule name should include `x86` rather than separately listing `i586`, `i686` and `x86_64`, and if a rule applies to all ELF platforms, it should be named `elf` rather than listing every ELF OS).
* Use an appropriately descriptive, but short, name if the language does not provide one.
Expand Down

0 comments on commit 0ab2181

Please sign in to comment.