The Google style guide is what we chose for Geode when we couldn't use
the Elements book
Le 10/14/2016 à 4:03 PM, Kirk Lund a écrit :
+1 to a) embracing https://google.github.io/styleguide/javaguide.html 100%,
b) adopting the google formatters for IntelliJ and Eclipse, c)using spotless
On Fri, Oct 14, 2016 at 6:56 AM, Jacob Barrett <jbarr...@pivotal.io> wrote:
On Thu, Oct 13, 2016 at 10:04 AM Kevin Duling <kdul...@pivotal.io> wrote:
Given that, +1 from me!
On Thu, Oct 13, 2016 at 9:51 AM, Jared Stewart <jstew...@pivotal.io>
The task is fully suppressible with -x spotlessCheck. Also, if you
any formatter errors you can automatically fix them with 'gradle
On Oct 13, 2016, at 9:40 AM, Kevin Duling <kdul...@pivotal.io>
If we made formatting a warning, then people would probably quickly
If we made formatting an error, we need to be sure we don't get in to
situation where <editor of choice>'s formatter is not in agreement
I can live with an additional 17 seconds as well. And Jared's
reduced the build time locally by 50%. But I still want the ability
suppress the check similar to -x javadoc.
On Wed, Oct 12, 2016 at 9:58 PM, William Markito <
This sounds really good to me as well. +1
On Wed, Oct 12, 2016 at 4:13 PM, Jared Stewart <jstew...@pivotal.io
This is running locally on my laptop. Since Spotless is only doing
formatting and not any other static analysis, it already has 0
(Other than, of course, formatting not consistent with the
On Oct 12, 2016, at 4:11 PM, Kenneth Howe <kh...@pivotal.io>
Agree with Mark, this has to work with 0 errors before it would be
useful in precheckin. I think I could live with an additional 17
most of the time for running the spotlessCheck as suggested.
Jared, Is that 17 seconds running locally on your laptop or on a
On Oct 12, 2016, at 3:39 PM, Jared Stewart <jstew...@pivotal.io>
If you want to try it out, I pushed a branch to my Geode repo
contains this change:
On Oct 12, 2016, at 2:27 PM, Darrel Schneider <
I like Dan's idea of catching formatting issues earlier but I
5-10 minutes to "build" would be too much. Currently when I'm
a quick build I use -xjavadoc. I'd probably do the same for this
it was part of build until I'm ready to do a precheckin.
Mark, wouldn't running the formatter on all our java files and
them in get these issues down to 0?
On Wed, Oct 12, 2016 at 12:53 PM, Udo Kohlmeyer <
+1 - adding checkstyle to precheckin.
If the developer uses the provided templates ( eclipse +
most of the formatting issues should be handled before
a developer has a questionable coding style, that should lessen
developer will have resolve the issues before being able to
I also believe that this should not be an overbearing and
On 13/10/16 6:36 am, Mark Bretl wrote:
There is some extra amount of time, 5-10 minutes extra for the
project (depending on your CPU). I think the real issue to
precheckin target and have it be 'effective' is it needs to
successfully, otherwise it would turn into noise most of the
We need to get the issues down to 0 or manage to set a new
the best idea), which is a lot of work, to make it run
now, if you run the target, it will fail every time since
issues in the code and very hard to tell what issues were
On Wed, Oct 12, 2016 at 11:34 AM, Dan Smith <
Seems like it should run as part of the build target. The only
make it part of precheckin is if it takes a long time,
should get fast feedback they need to change their code
On Wed, Oct 12, 2016 at 11:24 AM, Jared Stewart <
+1 to running during the precheckin target as well as Travis
On Oct 12, 2016 11:20 AM, "Darrel Schneider" <
If Travis CI is only run on pull requests then that is not
committers do not submit pull requests. Having it run during
build or precheckin target is also needed. In addition to
wanted PRs to be checked.
On Wed, Oct 12, 2016 at 11:12 AM, Jared Stewart <
It would certainly be necessary to make sure that the code
enforced is sensible, e.g. doe not use wildcard imports. We
want to make one large commit to format all existing code
Mark - Thank you for the information about the existing
Mark, Darrel, Kevin - Given all of your comments, I think
more sense to add the flag to enable it in Travis CI rather
of the build. This way your build pass regardless of
CI job would fail on PRs if they did not adhere to the
Anthony - It doesn’t seem to me that turning this on would
of combining reformatting commits and logic changes.
code would already be formatted, there would no longer be
commits except for single large commits when the code
On Oct 12, 2016, at 11:01 AM, Bruce Schuchardt <
I like the idea of doing this but I don't think
enabled until all of the code is reformatted.
Also, last time I checked there was still a problem with
auto-format settings. It still used wildcard imports,
don't allow. I've manually changed my settings in
to "Use single class import" to correct that problem. I
to get Gradle to do it.
Le 10/12/2016 à 10:28 AM, Anthony Baker a écrit :
Source code with a consistent look-and-feel makes it
to join the project community and contribute.
Let’s continue to keep reformatting commits separate from
changes—otherwise it’s too hard to review.
On Oct 12, 2016, at 10:06 AM, Dan Smith <
This might be a good time to reformat the code since I
are too many long lived feature branches outstanding.
On Wed, Oct 12, 2016 at 10:00 AM, Jared Stewart <
I would like to advocate for adding a Checkstyle <
sourceforge.net/> or Spotless <
gradle task to our build process to ensure that all code
the formatting standards described on the wiki <
confluence/display/GEODE/Code+Style+Guide> (and in the
formatter xml files in our repository). This will
reviewing code when whitespace or formatting has changed
checked in will already comply with standards.