Code Guidelines

Code formatting [required]

  • Marko will provide a code formatting description for Maven, perhaps files for IntelliJ and Eclipse code formatting, it will not be /that/ rigid. It will impose conventions on:
  • line length (120 chars)
  • whitespace handling (spaces instead of tabs)
  • indentation width (4 chars, ok?)
  • format definitions for IDEs

Variable naming [required]

SUN code style:
  • constants (static final): capital letters
  • members: "m_" prefix followed by lower case
  • no prefixes or restrictions on other variables, only: beginning with lower case letter

JavaDoc [recommended]

JavaDoc comments should exist at least for
  • class description
  • package.html
  • public, non-self-explanatory methods

Interface naming [required]

  • Java Interfaces shall not contain a general interface prefix (unlike "IMyInterface")

Runtime config file location [recommended]

  • configuration files for an application should be located in the classpath or an application directory in the user home directory

Documentation, general [required]

  • use english language

XML tag naming [recommended]

  • element name: first letter uppercase, camel case
  • attribute name: lower case letters

File naming (except java sources) [recommended]

  • only lower case letters, words separated by underscore ("_")

Testing (unit testing) [required]

  • best: no platform specific tests, if not possible to avoid, define a "test suite" (see JUnit documentation) so test classes succeed on all systems

Library usage

  • use of new libs in 52n-security-api and -apps modules has to be coordinated [required]
  • logging: all new modules shall use commons-logging (e.g. instead of log4j)

Coding style best practices [recommended]

  • exceptions & logging: only log error in catch block, if exception is not forwarded to avoid multiple exception logging
  • [tbc]

Release Guidelines / branches

Branching

Inside this working group we follow the Deferred Branching plus LAG Development Line model.

branch-late.gif

Deffered Branching means: A release branch is split of as soon as "work for that release starts to conflict with work that is already on the codeline

LAG Development Line means: The main trunk contains the "latest-and-greatest" code base that is successively growing

See the detailed "Streamed Lines" branching patterns site for more information.
ISorted ascending Attachment Action Size Date Who Comment
eclipse_code_formatter_52n.xmlxml eclipse_code_formatter_52n.xml manage 26 K 24 Oct 2007 - 10:31 UnknownUser Eclipse (3.2) code formatter definitions
eclipse_code_formatter_52n_1.1.xmlxml eclipse_code_formatter_52n_1.1.xml manage 26 K 06 May 2008 - 20:10 UnknownUser version 1.1
Topic revision: r8 - 15 Oct 2014, EikeJuerrens
Legal Notice | Privacy Statement


This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki? Send feedback