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.

Topic attachments
I Attachment Action Size Date Who Comment
XMLxml eclipse_code_formatter_52n.xml manage 26.6 K 2007-10-24 - 10:31 JanDrewnak Eclipse (3.2) code formatter definitions
XMLxml eclipse_code_formatter_52n_1.1.xml manage 26.6 K 2008-05-06 - 20:10 JanDrewnak version 1.1
Tags:
create new tag
, view all tags
Topic revision: r8 - 2014-10-15 - 14:03:32 - EikeHinderkJuerrens

 
  • Search: 
This site is powered by the TWiki collaboration platform Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback