[hibernate-dev] [SEARCH] Code style - imports

[Sanne Grinovero]

Fundamentally no IDE will ever produce exactly the same code so you
need to learn control your primal lust for perfection and remember
it's not relevant. Have some decency ;)

What does actually matter is that we don't keep chaging the order as
it introduces conflicts on backporting, it's very annoying and time
consuming in the long run.

My solution is simple: I don't generally care, BUT commits containing
code reformats just for the sake of making one's favourite tool happy
need be rejected, especially to stop the bad habit from developing
further, or anyone trying to impose its own favourite tool of the day
as it was the only blessed way.
It's fine if a couple of import reorg "slip in" as part as meaningful changes.

The real problem is that applying a patch shouldn't conflict on import
statements; ideally there should be a conflict resolution strategy
able to understand it better (e.g. teach Java to git tools..)

If you want to volunteer making the styles a bit more similar, I
typically prefer static imports last.

-1 for CheckStyle rules unless you can figure out a way to exclude
existing code from failing: we're not going to reformat half the code
base to satisfy aesthetics.

Perhaps we could have separate sets of rules, some stricter to be
applied on new modules; their impact would be limited but even having
one module with strict rules would encourage people to reconfigure
their IDE in "the right way". This would ensure all new code will be
consistent with the rules.

Sergey sent a related PR but I'm not sure what to think of it as it
changes several things:
 - https://github.com/hibernate/hibernate-ide-codestyles/pull/3

Thanks,
Sanne



On 12 September 2017 at 08:42, Yoann Rodiere <yoann at hibernate.org> wrote:
> Hello all,
>
> I just noticed that our IDEA codestyle configuration files have specific
> rules about how to organize imports, whereas the Eclipse ones don't.
> The most noticeable difference: organizing imports in Eclipse puts static
> imports at the top, while in IDEA they end up at the bottom. But there are
> other differences.
> The Hibernate ORM codebase doesn't seem affected by these inconsistencies
> (probably because most people working on it use IDEA), but in Hibernate
> Search we've already reached the point where half of our files follow one
> convention, and the other half follows the other.
>
> What's annoying here is not the inconsistencies themselves (I could live
> with that), it's more that in the long run we'll end up with tons of
> unnecessary changes in our commits, due to one person using IDEA to edit a
> file last edited with Eclipse, and vice-versa.
>
> To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot
> configure Eclipse to match the IDEA style exactly. In particular, we cannot
> configure where the static imports must go: they will always go to the top (
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415).
>
> I can see two ways out, each with its own drawbacks:
>
>    - Switch to the "Eclipse" style, and create a Search-specific IDEA code
>    style configuration, with static imports at the top. We won't be consistent
>    with Hibernate ORM, though.
>    - Switch to the "IDEA" style, and create a Search-specific Eclipse code
>    style configuration, as close as the IDEA style as possible. As I said
>    above, automatic import organizing in Eclipse will never follow this style
>    exactly, so it's likely to make organizing imports in Eclipse quite
>    painful. We could add checkstyle rules to make sure we strictly follow the
>    style even in Eclipse.
>
> WDYT?
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yoann at hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev