Skip to end of metadata
Go to start of metadata


  • No tabs in source code - only spaces.
  • Max line length - 120 symbols.


  • Java source files shouldn't be large, you should try to make them not more than 300 lines.
  • Use 4 spaces for indentation.
Classes & Methods and other stuff
  • If there is an abbreviation in class name, you should use camel style for them as well. E.g. UserDao, not UserDAO.
  • If you can't imagine any adequate name for implementation of some interface, name it InterfaceNameImpl.
  • Interfaces shouldn't use I at the start, and abstract classes shouldn't start with A. Bad style: IFigure, ARoundFigure.
  • Both classes and methods should be named in a self-explanatory way. If the name is too long, you could shorten it and add more information to JavaDocs, but you should think thorought about these names, they are very important.
  • if, for, while - all this stuff should have curved braces {} surrounding their body, even if it's only one line of code.
  • There are two types of exceptions in Java: checked and unchecked, you should wisely use them in your code. Read JavaTalks FAQ (ru) and an article of Barry Ruzek to fully understand what types of exceptions should be used and when.
  • If you have a method with an empty body and you don't want/can implement it, you must throw UnsupportedOperationException in its body.
  • While using BeanValidation, the property-level annotations should be preferred instead of field-leve. More details can be found in this JIRA.
  • JavaDocs should be present at next levels: packages, classes, methods, constants. Private methods might be an exception, but only if it's name and functions are really self-explanatory and they do not throw any unchecked exceptions, in other cases - you have to write full JavaDocs.
  • When you create a class or make serious amendmends, you should always put/add yourself as the author, use your first name and family name for these purpose.
  • Use {@code } instead of <code> in JavaDocs.
  • All sentences should end up with a dot if we're talking about general description. Exceptions are such directives: param, return, throw - they may not contain dots, but only if they consist of one sentence; if two or more - you have to put dots after each sentence.
  • If you implement/override some method and you follow the contract that is described by parent's JavaDocs, you should put {@inheritDoc} directive in JavaDocs of this new method. If you deviate from the contract, you should write full JavaDoc for it.
  • Copyright documentation should be added before package declaration within each java source code file.
  • Descriptions at POM files of Maven should contain information about module or set of modules. This information should be always up-to-date. If some environment variables should be specified in OS, this should be described. Information about how to deploy and start the application should be described in POMs as well.
  • README file should be present in each project folder and it should outline some general notes, but for more detailed information it should point to POMs.
  • Do not use excessively simple Java comments inside methods body, - only for places where there is a real need.
  • Put comments in Spring Context files - what these files are about if the file name may not cast light on its intentions.
  • Package name shouldn't contain any BIG letters or underscores.
  • Package name should consist of the JTalks project domain name, then it should include the name of concrete project (Antarcticle, JCommune, etc), and after that the module name it resides in. Example: "org.jtalks.poulpe.model"
  • Don't put a lot of classes in a single package, 20 is okay, 100 is too much.
  • Try to avoid circle dependencies between packages.


  • Use 2 spaces for indentation
  • If you deal with such short tags: <something attribute1="value" />, you should put a space between last attribute and slash.


  • Columns, constraints, tables should not use CamelStyle, nor they should contain small letters. This is how they should be named: COLUMN_NAME, TABLE_NAME, FK_NAME


  • Code coverage tests not less than 90%
  • Use DataProviders in order to separate preparation of test data and tests per se.

Resource Bundle

  • No camel case, use underscore to separate words (recent_activity=Recent Activity).
  • Use dots to separate places where the label is used, but don't use dots just to separate words (_topic.user_post_count=Post Count).
  • Use placeholders to finish the phrase within the text: (header.welcome_user=Welcome, {0}).




Id element - CamelCase 

Class of element