-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code Conventions #2
Comments
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. 😉 |
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 |
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 |
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:
|
Saw this change in the README:
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.
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 👍 |
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. |
Since the spotless config (Eclipse formatter xml) is now checked in and enforced in the build I'll close this issue. |
* Test AutoCloseExtension * Register extension as stateless Signed-off-by: Björn Michael <b.michael@gmx.de>
* Test AutoCloseExtension * Register extension as stateless Signed-off-by: Björn Michael <b.michael@gmx.de>
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.
The text was updated successfully, but these errors were encountered: