[
https://issues.apache.org/jira/browse/SAMZA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118990#comment-14118990
]
David Chen commented on SAMZA-36:
---------------------------------
Have we discussed possible coding styles we should consider adopting?
For Java, I think the two obvious styles are:
* [Hadoop coding style|https://wiki.apache.org/hadoop/CodeReviewChecklist],
which is the Sun coding convention with the exception of using half the number
spaces for indentation.
* [Google Java coding
style|https://google-styleguide.googlecode.com/svn/trunk/javaguide.html] which
is nearly the same except for allowing certain annotations like {{@Override}}
to be on the same line as the method. For example:
{code}
@Override public void doSomething() {
{code}
For Scala:
* The official [Scala Style Guide|http://docs.scala-lang.org/style/]. The only
thing I don't quite like about it is that split lines are also indented 2
spaces rather than 4 (two indents), which I think would be more readable.
* There is also Twitter's [Effective
Scala|http://twitter.github.io/effectivescala/]
> Define and enforce coding style
> -------------------------------
>
> Key: SAMZA-36
> URL: https://issues.apache.org/jira/browse/SAMZA-36
> Project: Samza
> Issue Type: Bug
> Components: build, docs
> Affects Versions: 0.6.0
> Reporter: Chris Riccomini
>
> We should define and enforce a coding style for Samza.
> 1. Define the coding style in English on the Coding Guide page.
> 2. Enforce the coding style using whatever mechanism works best (Checkstyle,
> Scalastyle, or a custom Gradle task).
> 3. Provide appropriate formatters for Eclipse and IDEA.
> We'll have to mess around and see what works best for this. I think we can
> make ./gradlew eclipse and ./gradlew idea generate
> projects/workspaces/settings with the appropriate code formatters using
> Gradle's Eclipse and IDEA plugins:
> * http://www.gradle.org/docs/current/userguide/eclipse_plugin.html
> * http://www.gradle.org/docs/current/userguide/idea_plugin.html
> In the Eclipse case, there is a task called eclipseJdt, which can take an
> input file, when generating the JDT file
> (.settings/org.eclipse.jdt.core.prefs).
> In the IDEA case, the same pattern can be followed. I'm not sure in IntelliJ
> if the settings are in the .ipr, ,iml, or .iws file, but it can handle all of
> these.
> I suggest we put the Eclipse and IntelliJ files in a folder called
> "gradle/config".
> Regarding enforcement, a pretty simple way to do this is to create a Gradle
> task that runs the Eclipse formatter, and then does a git diff to see if
> anything changed. See this page for details:
> http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line.
> {noformat}
> $ git diff --exit-code
> .. some stuff ..
> $ echo $?
> 1
> $ git checkout settings.gradle
> $ echo $?
> 0
> {noformat}
> An alternative enforcement mechanism is to use Checkstyle and Scalastyle,
> though I'm not sure Scalastyle is sufficient to enforce everything we need. I
> think the best approach is to just try them and see which one works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
