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