[
https://issues.apache.org/jira/browse/SAMZA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Riccomini updated SAMZA-36:
---------------------------------
Fix Version/s: 0.9.0
> 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
> Fix For: 0.9.0
>
>
> 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)
