I know I've been guilty of submitting code for review that hasn't matched the code style in the past. As a result, I've checked the "reformat code" box on the 'commit' dialog in IDEA, pointing to the IntelliJ xml formatter.
It's frustrating to me that this sort of thing is still an issue in software development. Ever since I've started my career, there's been arguments about whitespace; how far to indent and what line the curly brace goes on. And I'm yet to be convinced one way is superior to the other. What is easier for one to read is more difficult for another. While I'm developing and doing frequent local builds, I do not want a build to fail due to whitespace issues. So I am in favor of adding this if there is an option to disable like we can disable javadoc and tests, but enforce it by default and/or precheckin. On Wed, Oct 12, 2016 at 10:07 AM, Nabarun Nag <n...@pivotal.io> wrote: > +1 > > On Wed, Oct 12, 2016 at 10:06 AM Dan Smith <dsm...@pivotal.io> wrote: > > > +1 > > > > This might be a good time to reformat the code since I don't think there > > are too many long lived feature branches outstanding. > > > > -Dan > > > > On Wed, Oct 12, 2016 at 10:00 AM, Jared Stewart <jstew...@pivotal.io> > > wrote: > > > > > I would like to advocate for adding a Checkstyle <http://checkstyle. > > > sourceforge.net/> or Spotless <https://github.com/diffplug/spotless> > > > gradle task to our build process to ensure that all code checked in > meets > > > the formatting standards described on the wiki < > > https://cwiki.apache.org/ > > > confluence/display/GEODE/Code+Style+Guide> (and in the > intellij/eclipse > > > formatter xml files in our repository). This will alleviate > difficulties > > > reviewing code when whitespace or formatting has changed since all code > > > checked in will already comply with standards. > > >
