Unless it contradicts a rule written here, Oracle's Code Conventions for the Java Programming Language are used.

Whitespace

  • Use spaces, not tabs
  • Use 4 space characters to indent
  • A line should not exceed 100 characters
  • Lines should not contain trailing spaces.

Symbols

  • Always use braces around blocks, even single line blocks.
  • The opening brace is always on the same line as the if statement, except when you have multiple arguments.
if (arg1 ||
    arg2 < arg1 ||
    arg3)
{
  doSomething();
}
  • When breaking logic, || and && at the end of the line.
  • One instruction per line.
  • Always put else on its own line.

Function and variable names

  • Use US English for function and variable names.
  • Use full English words for variable names. Examples: documentProvider but not docProv, feedElement but not fdElt. Variable names reduced to a single letter should not be used, unless in indexes such as in for loops.
  • Do not prefix interface types with I, and do not prefix abstract types with Abstract

Comments

  • Comments should be in grammatically-correct US English, with full sentences that include punctuation.
  • Javadoc comments before classes or methods are not mandatory.
  • Don't include empty javadoc. Either the javadoc provides information and it's good to have it, or it doesn't and shouldn't be there.
  • Do not leave commented-out code in source files. If the code is no longer used, just delete it. We can always use the Git history to get it back if necessary. Similarly, delete any dead code.

General Java Guidelines

  • Do not use raw types: List<String> rather than simply List.
  • Do not leave useless import statements in the code.
  • Use the Override annotation whenever possible (but not for interface implementations as it breaks Java 5 compatibility).
  • Do not ignore exceptions (no try with an empty catch block). If you don't handle a checked exception you can either add a throw to your method declaration (if you believe the exception is worth staying checked) or throw it again as a RuntimeException if it's rare enough so users of your method shouldn't have to care.
try {
   // Code with a checked exception that shouldn't be checked
} catch(Exception e) {
   throw new RuntimeException(e); // This will propagate to the controller,
                                  // and the developer will see the exception in his web browser
                                  // (or it will be logged if in production mode)
}
  • Prefer enum to int constants.
New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2>Play framework</h2>

Play makes it easier to build Web applications with Java. It is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Learn more on the <a href="http://www.playframework.org">http://www.playframework.org</a> website.<br><br>

<h2>Source code is hosted on github</h2>Check out our repository at <a href="http://github.com/playframework/play">http://github.com/playframework/play</a><br><br>

<h2>Contributing, creating a patch</h2> Please read the <a href="http://play.lighthouseapp.com/projects/57987/contributor-guide">contributor guide</a><br><br>

<h2>Reporting Security Vulnerabilities</h2> Since all bug reports are public, please report any security vulnerability directly to <em>guillaume dot bort at gmail dot com</em>.<br><br>

<h2>Creating a bug report</h2> Bug reports are incredibly helpful, so take time to report bugs and request features in our ticket tracker. We’re always grateful for patches to Play’s code. Indeed, bug reports with attached patches will get fixed far quickly than those without any.<br><br>

Please include as much relevant information as possible including the exact framework version you're using and a code snippet that reproduces the problem.<br><br>

Don't have too much expectations. Unless the bug is really a serious "everything is broken" thing, you're creating a ticket to start a discussion. Having a patch (or a branch on Github we can pull from) is better, but then again we'll only pull high quality branches that make sense to be in the core of Play.

1.4.x4% complete

 

Completed 2 of 48 tickets

Pages