Well, if you don't mind me sending PRs with those imports in a different order next time I change the file (because I don't spend time on organizing imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that undefined.
Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On 12 September 2017 at 11:45, Sanne Grinovero <sa...@hibernate.org> wrote: > On 12 September 2017 at 10:42, Yoann Rodiere <yo...@hibernate.org> wrote: > >> 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 ;) > > > > > > Sorry if that seemed "indecent", but I did mention that I could live with > > the inconsistencies, and that what matters is their effect on our git > > workflow :) > > > >> If you want to volunteer making the styles a bit more similar, I > >> typically prefer static imports last. > > > > > > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try > to > > align the rest of the rules, though. > > > >> 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 > > > > > > Yes, it does more than what it advertises, and even the original idea > > (putting static imports to the top) is not a good idea: ORM already has > > static imports at the bottom in almost every file, so this change would > lead > > to many more changes than necessary in commits for the ORM project for > some > > time. > > > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > > > > > > I doubt they'll ever agree with this solution. And I can't blame them. > > > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > > > > > > Seems to be the least disruptive solution. It's not ideal, but it should > > improve the situation slightly and it wouldn't lead to more changes than > > necessary in the future git commits. > > @Sanne this means the imports will stay at the top, though. Ok with that? > > Yes I'm "ok" with that. But wouldn't it be even better to leave this > level of detail undefined? > > At least it would allow me to make new code having them on the bottom > as I like them more, and you'd save some itme :) > > > > > I'll try to see if I can add non-disruptive checkstyle rules too, if I > have > > some time. > > > > Yoann Rodière > > Hibernate NoORM Team > > yo...@hibernate.org > > > > On 12 September 2017 at 11:31, Guillaume Smet <guillaume.s...@gmail.com> > > wrote: > >> > >> Hi, > >> > >> Yes, I had a hard time reverting the import changes in my recent patches > >> for ORM. I was changing only a few lines per file and had a lot of > import > >> noise. > >> > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > >> > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > >> > >> -- > >> Guillaume > >> > >> > >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero <sa...@hibernate.org> > >> wrote: > >>> > >>> 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 <yo...@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 > >>> > yo...@hibernate.org > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev@lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
