Code Conventions

[schauder]

It would be nice to have some code conventions defined, to make it easier for non-core-committers to provide useful pull requests.

Ideally they would come with formatters/checkstyle configurations.

[sbrannen]

Don't worry.

We will definitely having coding conventions in place once we get to the point where we are accepting pull requests.

At this time we are simply focusing on the functionality and feasibility of the prototype.

Since most of the code will likely be rewritten or thrown away, coding conventions are a moot point for the time being. 😉

[kcooney]

JUnit moved to.the Google Java Style Guide, except we kept the indentation of existing files at four spaces.

See https://github.com/junit-team/junit/blob/master/CODING_STYLE.txt

[kcooney]

FYI: there is a checkstyle config for the Google Java Style Guide: http://checkstyle.sourceforge.net/google_style.html

See also https://agilewarrior.wordpress.com/2015/08/07/how-to-add-intellij-google-style-guide-to-intellij/ and https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml

[nedtwigg]

Whitespace is certainly not the most important part of a project, but if you put stylechecking into the build while the project is still young, then it ensures that your project history from will be clean of formatting noise so you can focus on the content. I submitted two PR's above:

• the first enforces a style guide, using rules that closely match the exising style
• the second is the same as the first, but with an extra commit to switch to the Google style

[nedtwigg]

Saw this change in the README:

The goal of the prototype is to get feedback on the API. Focusing on code style, formatting and other details will distract the community's (and our) attention.

I agree that formatting is a minor concern, so I won't distract further after this comment. But the pull-requests I submitted to help with formatting now have a merge conflict because of a meaningless whitespace change.

As someone who doesn't care what style the code is in, but just wants to follow the evolution of the code, it's distracting to filter through formatting changes. The commit which introduced conflicts for the PRs also swapped the order of imports in several places, without actually changing what was imported.

Be regular and orderly in your life, so that you may be violent and original in your work.
- Gustave Flaubert

Your code already has a style, but without tools us humans are going to be inconsistent and distract from the meaning of the actual code. Which isn't a big deal, but I'm still gonna preach for using the tools that we have to get rid of that noise.

Can't wait to use what you guys come up with 👍

[bechte]

Yeah, sorry about that. We didn't use spotless at this time. Now we are reformatting with the common code style before each commit to avoid this in the future. Still, this is still prototyping and we are focussing features. I agree that it is not easy to contribute right now, but it will be in the future when we have a early alpha. Thanks for your feedback.

[jlink]

Since the spotless config (Eclipse formatter xml) is now checked in and enforced in the build I'll close this issue.