Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Cached Google Style is slightly outdated and not like original #6619
If you compare http://google.github.io/styleguide/javaguide.html and https://checkstyle.org/styleguides/google-java-style-20170228.html, you that it is displayed differently, for example original
Also the cached version got some minor changes that as far as I have seen do not change meaning, just add some clarification, as can be seen here: https://github.com/google/styleguide/compare/594d91bfbb8dfcbcac0f148af8175f2b7ec9857b...91d6e367e384b0d8aaaf7ce95029514fcdf38651#diff-b6c9191ee5ccb7a5ef170e98e51d94d8
I'd like to suggest to update the cached version with a recent one that contains latest changes and also displays correctly.
referenced this issue
Mar 30, 2019
The link says "There isn’t anything to compare.".
Nothing is usually ever as simple with the google style. We would have to review every change and agree that nothing needs to be changed on our side for each module. We have worked hard to do our best with matching their guide, so we need to continue doing it with each update.
Here is possibly one example I am seeing from their webpage:
We don't support this as seen with #5089 .
So we can't update our cache until we are sure we support all google's rules or possibly agree that we can't ever support them. Example: http://checkstyle.sourceforge.net/google_style.html#a5.2.4
we can update cached version, only if there is no java style changes but there is some formatting changes in HTML layout so to look better.
If there is some style changes, we have to address them in our mapping page, while copy new version of style guide.
If you udpate this issue description with clear definition of style differences I can approve the issue.
I see diff as https://www.diffchecker.com/KVRGxmti (if link does not work, copy html content from both pages )
Stupid GitHub-style markdown parser destroyed the link by removing the
Of course, that's why I posted the link with the differences that now also works.
But I can of course post them here again as images for reference:
4.4: As mentioned by @rnveach, #5089 shows this is false, but I would tend to say this is simply a bug and even in the current cached version there should be no green checkmark. The additional text just explains what was meant by the word character, but it was no content change, the rule is the same and is not followed correctly currently by checkstyle.
4.6.1: imho just nicer language, no content change
4.6.2: This one I actually overlooked initially. I think there is no rule yet to check these two? Actually for the ellipsis case there is even a rule in the checks that checks the opposite. (
5.1: imho just nicer language, no content change
5.2.3: mainly nicer language and not fully covered regarding the clarified point anyway
5.2.4: Not covered anyway, change is just single underscore forced
Of course, as mentioned originally I thought there were only lingo changes and clarifications, while one is discutable and one I just missed.
Not really necessary to use some differ, as the style is maintained in a GitHub repository. :-)
I added in my local branch the mention of #5089 for 4.4 which is only partly covered anyway and changed 4.6.2 to partly covered with explanation about the new cases. Actually 4.6.2 is only partly covered anyway, for example it is not checked that there is no space before
I'll push it as soon as we agreed and you reopened my PR.
we have a bug on unicode symbol usage and LineLength from google people, we need to mention it in mapping.
agree, no functional changes.
ok, lets convert to partly covered, and create issue that address certain items to update.
the rest items are fine.
@rnveach , I am agree to change our style guide, only if we clearly define what new items we do not cover and provide links to issues. We just need to honest with users.
@Vampire , thanks a lot for analysis but lets make sure that in new coverage change image on item if we do not cover it completely and reference issues in mapping table that need to be fixed to make full coverage or improve coverage.