checkstyle / checkstyle

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. By default it supports the Google Java Style Guide and Sun Code Conventions, but is highly configurable. It can be invoked with an ANT task and a command line program.
https://checkstyle.org
GNU Lesser General Public License v2.1
8.29k stars 3.66k forks source link

One letter words should be tolerated when following Google style #14239

Closed oliviercailloux closed 8 months ago

oliviercailloux commented 8 months ago

Following the Google Java Style Guide, the name of a class that represents an X key could be XKey. Similarly, the name CCompiler strictly adheres to the GJSG.

Checkstyle considers that the GJSG forbids two consecutive upper case letters, and indeed the GJSG does forbid this in the most usual case where words are all more than one letter. But in the (arguably very special) case of the X windowing system (not to mention the infamous social network), X is a word; similarly, C is a word in the phrase I am designing a C compiler.

So, following the GJSG seems to require to add all one-letter words, such as “X”, or “C” or “R” (the languages), as “allowed abbreviations” (using the allowedAbbreviations parameter).

Arguably, perhaps some could consider Y and Z as words, such as in this example (though this can be contested as this person seems to be talking about the XY problem, in which case Y is not a word).

So perhaps instead of wondering about the full list of one-letter words which should be considered as belonging to the English language, Checkstyle should rather modify the allowedAbbreviationLength to 1 in its google checks file, which I believe is equivalent to consider all letters as possibly forming a single-letter word.

In both cases, something should be changed in https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml so as to follow more closely the GJSG.

(I hope it is okay to not provide a reproducible example as this discussion is conceptual, not trying to illustrate a specific example where Checkstyle has a bug.)

romani commented 8 months ago

the name of a class that represents an X key could be XKey

Please share a quote from style guide that explicitly allows this.

oliviercailloux commented 8 months ago

the name of a class that represents an X key could be XKey

Please share a quote from style guide that explicitly allows this.

Thanks for considering the request. Sure, here is the relevant part (about upper camel case) and my deduction.

Beginning with the prose form of the name:

  1. Convert the phrase to plain ASCII and remove any apostrophes. For example, "Müller's algorithm" might become "Muellers algorithm".
  2. Divide this result into words, splitting on spaces and any remaining punctuation (typically hyphens).
    • Recommended: if any word already has a conventional camel-case appearance in common usage, split this into its constituent parts (e.g., "AdWords" becomes "ad words"). Note that a word such as "iOS" is not really in camel case per se; it defies any convention, so this recommendation does not apply.
  3. Now lowercase everything (including acronyms), then uppercase only the first character of: ... each word, to yield upper camel case (…)
  4. Finally, join all the words into a single identifier.

Starting with the prose form “X key”, this yields:

  1. X key
  2. X key
  3. X Key
  4. XKey
romani commented 8 months ago

in Google style there is example: "supports IPv6 on iOS?" ----> supportsIpv6OnIos

attention to "iOS" it become a term/word, so "Ios".

so

name of a class that represents an X key

is term, so Xkey.


you have full right to interpret this in your own way. Your options: use ''allowedAbbreviations", example: https://checkstyle.org/checks/naming/abbreviationaswordinname.html#Example3-config or use any https://checkstyle.org/filters/index.html that referenced at https://github.com/checkstyle/checkstyle/blob/66e2223e64a7af578c16b57100f7cda485425cd7/src/main/resources/google_checks.xml#L362-L380 to suppress names that you think make sense to you.

We will not change common config, as there will be another bunch of people who disagree. Style discussions are very controversial and very subjective, so should be reconciled by filtering/suppression for specific projects/teams/cases. Each rule has exceptions, so do not hesitate to use suppression.

oliviercailloux commented 8 months ago

iOs is a term by itself, indeed. It is not composed of the words “I” and then the word ”Os”. My claim is not about “iOs”, it is about such phrases as “X key” (referring to the X system) or “C compiler” (referring to the C language), where ”X” and “C” are words that are combined in the usual sense of combining words in a natural language to (any) other words. In “The C programming language”, there is no such thing as a word spelled as “Cprogramming”, but there are separate words: the word C, and the word programming.

There are parts where the GJSG is ambiguous (which it acknowledges when referring to ambiguously hyphenated words in English), but when wondering whether the phrase “The C programming language” could be interpreted as being composed of three words, as if it could be written “The Cprogramming language”, we are not facing a multiplicity of reasonable interpretations.

romani commented 8 months ago

You have full rights to change Google style config as you want and use it for your projects.

We already made property allowedAbbreviations to ease usage. We will not do more.

By your logic ABCDEFGKey is also ok, if you need it, sure, in your config and project you define what is good. Changes in common implementation, should satisfy most common usage.

oliviercailloux commented 8 months ago

You have full rights to change Google style config as you want and use it for your projects. We already made property allowedAbbreviations to ease usage. We will not do more.

Sure, that was clear, I just couldn’t refrain from defending my argument as I (still) think that it is correct.

By your logic ABCDEFGKey is also ok

… and I again can’t refrain from writing that, no, this does not follow from my logic, on the contrary.

Thanks for considering the request anyway, and for a great tool.

romani commented 8 months ago

You can open issue on Google style, if they agree to update style guide to mention this edge cases as valid, we will reconsider our decision, but for now this is how we interpret Google style.