Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

On a side note, having automatic formatting was really nice. I think it is the right direction. If we only had a way to tweak a few rules like the max line length, one-line Javadoc and maybe consider using the Google format for 1.8 cause we are using the 1.7 format at the moment, which was not d

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Probably worthwhile to really think about the long-term desired outcomes. Even a large, one-time, disruption of the codebase for the sake of future consistency could be quite valuable. Remember you'll also lose fidelity with history/blame. At some point a 'breaking' ( in a different sense ) chang

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

It is the right direction to remove the trivial part of the coding. Just wondering why we change the max line length from 120 to 100. Best, Yufei `This is not a contribution` On Fri, Jul 29, 2022 at 9:21 AM Austin Bennett wrote: > Probably worthwhile to really think about the long-term desir

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Austin, I don’t think anyone questions the value of consistent code or the value of automatic formatting. It is quite the opposite, actually. I think everyone on this thread actually cares about those things :) Was automatic formatting helpful? For sure! Did changing the line limit from 120 to

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Is line length something that we can fix? That seems like a reasonable change to Google style that we may be able to do something about. On Fri, Jul 29, 2022 at 9:52 AM Anton Okolnychyi wrote: > Austin, I don’t think anyone questions the value of consistent code or the > value of automatic forma

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Agreed. I also haven't contributed much to the project yet, so my opinion shouldn't carry much weight -- and really have no preferences for 120 or 100. Strongly encouraged to think at least 4+ years ( if not 2x++ what it already has existed ) ahead for the project [ Iceberg will be around for at

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

The only reason we have to stick to the *google-java-format* 1.7 is because CI is running with both JDK 8 and 11. Depending on the underlying JDK version a different *google-java-format* is being automatically picked up. If you run *spotlessApply* with JDK 11, CI with JDK 8 will run *spotlessCheck*

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

I looked at *palantir-java-format *previously and It is true that it uses 120 chars line length, but it also uses a different indentation multiplier

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

I am afraid it is not easily possible. I looked into it a bit and even if we create a custom formatting step in Spotless (easy), there is no way to simply change the line limit. We would have to fork the Google format lib. I don’t think it is worth. Let’s just stick to 100 then. - Anton > On J

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Thanks for the auto formatting initiative, I think its really a time saver. I also agree about the line length, it would be better to keep it at 120 and a bummer it has to be reduced to 100 now. Looking at palantir-format, I actually like some of their format choices like line-length and also not

Re: [DISCUSS] Automatic Code Formatting / Code Style / Enforcing Code Style

Has anyone looked into eclipse-jdt or have any experience with that in the past? Any ideas on how to change the max line length in the Google format? I know it is their deliberate choice not to expose that config but I would not mind a workaround. - Anton > On Jul 29, 2022, at 5:58 PM, Szehon