Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
google_checks.xml CustomImportOrder problem #941
The Google Java Style Guide specifies the import ordering to have
This is a problem for people using these rules on their project, but importing Google code, like Guava. It seems like this would much more appropriately be applied with
It's also not clear to me that the THIRD_PARTY_PACKAGE or STANDARD_JAVA_PACKAGE rule is correctly dividing things into separate groups "one group per top-level package". It seems CustomImportOrder needs an additional configuration option to separate
I'm not even sure there's a good workaround, short of copying/pasting the entire
referenced this issue
Apr 17, 2015
We created that option exactly for this, most likely we just fogot to use it when did configuration and guava report generation. We could use it but we need to recheck that guava report is the same.
Please describe your concers in detail, i do not understand a problem. Standard packages are configurable, all thirdparty is all that does not match any other group.
I always advice to use your own style, it is a rare case when rules of one team are ok for another team. We will deliver Google style with complete focus to their style guide, to show that our project could satisfy even demanding requirements.
There is no inheritance for configs, or using few configs.
Google defines (
(Personally, I think all this grouping is kinda dumb for the Google Style. I'd rather just: alphabetized static imports, blank line, alphabetized non-static imports, but unfortunately that's not what the Google Style Guide has chosen, so it makes checkstyle enforcement a lot more complicated.)
I suspect many projects find it easier to adopt one of the available standards rather than write their own, especially since the
And for the most part, it does so successfully. I think imports are one of those few areas where there remains a (slight) mismatch between the requirements and the abilities of checkstyle.
But also, please keep in mind that Checkstyle's users don't necessarily just use it just as an example. It's actually a reasonable way to enforce a standard which users may adopt.
Thanks. The ability to override might be a feature I'd want to take up with the
Are you sure ?
here you are describe your preferences and your vision of style. It is good , but here we follow strict document requirements. But by experience of discussion with Guava team I got to know that even Google's is not defined clearly and a lot have to be changed at document. Please read - google/guava#1891
yes, it is good, but Google use only third part of all static analysis that our tool provide. Following to Google is better then nothing but eventually you will change a config.
we could sort imports string :) , we might not be able to satisfy your requirements, but this is another discussion.
please provide a config that you would like to have that covers Google and satisfy you (with SAME_PACKAGE usage), please test your new config as described there https://github.com/checkstyle/checkstyle/wiki/How-to-generate-Checkstyle-report-for-Google-Guava-project and prove that change does not generate any violations over guava project.
I'm sure about the Google Java Style description for imports, yes. The requirements are quite clearly documented. I'm less confident about
Yes, apologies for any confusion. That was intended solely as a parenthetical comment, an aside. I was merely expressing a slight frustration with Google's choices to have such complex import requirements.
To be clear, the import order requirements I'm describing in this issue are from the Google Style Guide for Java, and not my own.
FWIW, Guava isn't really a very good test for the
looks like we did not noticed "one group per top-level package" from "Third-party imports, one group per top-level package, in ASCII sort order for example: android, com, junit, org, sun"
Examples for muli-thirdparty and javax:
We need to investigate why Check we have one macros for thirdparty and one option
here is a beginning of discussion with original author: https://groups.google.com/d/msg/checkstyle-devel/E0z89fzvxGs/li4gPrstLZAJ it might be useful to understand why we did that in such way.
So there are 2 requests:
For _#_2 I see 2 options:
B) Provide ability for user to specify more groups on CustomImportOrder configuration. It will require manual configuration every time when new top-level domain is added to source code (and the same configuration should be done on IDE, see previous comment).
@romani Could you please comment with your vision?
@ekuefler, can you share what IDE settings your team use to sort imports?
I tested on Guava "STATIC###SAME_PACKAGE(2)###THIRD_PARTY_PACKAGE###STANDARD_JAVA_PACKAGE" vs "STATIC###SPECIAL_IMPORTS###THIRD_PARTY_PACKAGE###STANDARD_JAVA_PACKAGE", both give a 0 violations.
I do believe that such code is not formatted well to style guide, and as Checkstyle is not used in build - it is very easy to miss/forget.... .
We could describe in documentation that option is applicable to THIRDPARTY and STANDARD groups only. It is better then deprecate existing option and provide two new options.
I thought it is possible to make config like following to avoid problems you describe.
Interesting examples of google's code - https://github.com/android/platform_development/tree/master/ide
IntelijIdea config is not following Style guide (static are below, no alphabetical order) - https://github.com/android/platform_development/blob/master/ide/intellij/codestyles/AndroidStyle.xml#L19 , BUT we see how "com.google" is separated to the top as it demand style guide.
Eclipse config - https://github.com/android/platform_development/blob/master/ide/eclipse/android.importorder - but here there is no reference to special "com.google" at all (most likely android does not have sources from at "com/google" folders)
Alternative proposal from @ivanov-alex is to use http://checkstyle.sourceforge.net/config_imports.html#ImportOrder that is designed the same way as IDEs formatters. In config just specify most common domain of first level from https://repo1.maven.org/maven2/ , or grab list from Eclipse settings of Android project (see link above).
Chromium project does not use Google Style config that we host and use its own - https://code.google.com/p/chromium/codesearch#chromium/src/tools/android/checkstyle/chromium-style-5.0.xml&l=164
Nine days ago the guidelines for import formatting have been simplified drastically: google/styleguide@b075cb7
Now the only requirements are that static imports come first, then all other imports in one group. These two groups are separated by an empty line (if both groups are present). And both groups are still sorted alphabetically in ASCII order.
I prepared a pull request to reflect for this change: #3363.