+1 to automating this with Gradle and never have problems with formatting/forgetting about it again! :)
śr., 27 cze 2018 o 07:40 Tim Robertson <timrobertson...@gmail.com> napisał(a): > ++1 > > > On Wed, Jun 27, 2018 at 7:36 AM, Ahmet Altay <al...@google.com> wrote: > >> +1 >> >> This is great idea. Does anyone know a similar tool for python? I believe >> go already has this as part of its tools with go fmt. >> >> >> On Tue, Jun 26, 2018 at 9:55 PM, Ankur Goenka <goe...@google.com> wrote: >> >>> +1 >>> >>> Intellij can help but still formatting is an additional thing to keep in >>> mind. Enabling auto formatting at gradle level will remove this additional >>> thing to keep in mind. >>> >>> On Tue, Jun 26, 2018 at 9:49 PM Eugene Kirpichov <kirpic...@google.com> >>> wrote: >>> >>>> +1! >>>> >>>> In some cases the temptation to format code manually can be quite >>>> strong, but the ease of just re-running the formatter after any change >>>> (especially after global changes like class/method renames) overweighs it. >>>> I lost count of the times when I wasted a precommit because some line >>>> became >100 characters after a refactoring. I especially love that there's >>>> a gradle task that does this for you - I used to manually run >>>> google-java-format-diff. >>>> >>>> On Tue, Jun 26, 2018 at 9:38 PM Rafael Fernandez <rfern...@google.com> >>>> wrote: >>>> >>>>> +1! Remove guesswork :D >>>>> >>>>> >>>>> >>>>> On Tue, Jun 26, 2018 at 9:15 PM Kenneth Knowles <k...@google.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I like readable code, but I don't like formatting it myself. And I >>>>>> _really_ don't like discussing in code review. "Spotless" [1] can >>>>>> enforce - >>>>>> and automatically apply - automatic formatting for Java, Groovy, and some >>>>>> others. >>>>>> >>>>>> This is not about style or wanting a particular layout. This is about >>>>>> automation, contributor experience, and streamlining review >>>>>> >>>>>> - Contributor experience: MUCH better than checkstyle: error message >>>>>> just says "run ./gradlew :beam-your-module:spotlessApply" instead of >>>>>> telling them to go in and manually edit. >>>>>> >>>>>> - Automation: You want to use autoformat so you don't have to format >>>>>> code by hand. But if you autoformat a file that was in some other format, >>>>>> then you touch a bunch of unrelated lines. If the file is already >>>>>> autoformatted, it is much better. >>>>>> >>>>>> - Review: Never talk about code formatting ever again. A PR also >>>>>> needs baseline to already be autoformatted or formatting will make it >>>>>> unclear which lines are really changed. >>>>>> >>>>>> This is already available via applyJavaNature(enableSpotless: true) >>>>>> and it is turned on for SQL and our buildSrc gradle plugins. It is very >>>>>> nice. There is a JIRA [2] to turn it on for the hold code base. >>>>>> Personally, >>>>>> I think (a) every module could make a different choice if the main >>>>>> contributors feel strongly and (b) it is objectively better to always >>>>>> autoformat :-) >>>>>> >>>>>> WDYT? If we do it, it is trivial to add it module-at-a-time or >>>>>> globally. If someone conflicts with a massive autoformat commit, they can >>>>>> just keep their changes and autoformat them and it is done. >>>>>> >>>>>> Kenn >>>>>> >>>>>> [1] https://github.com/diffplug/spotless/tree/master/plugin-gradle >>>>>> [2] https://issues.apache.org/jira/browse/BEAM-4394 >>>>>> >>>>>> >> >
