Coding Style and other Standards

This document attempts to explain the basic styles and patterns that are used in the ]po[ codebase. New code should try to conform to these standards so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

This is particularly directed at people new to the ]po[ codebase, who are in the process of getting their code reviewed. Before getting a review, please read over this document and make sure your code conforms to the recommendations here.

Naming and formatting code

The following norms should be followed for new code.

Whitespace

  • No whitespace at the end of a line
  • Unix-style linebreaks ('\n'), not Windows-style ('\r\n')

Line length

  • 80 characters or less (for laptop side-by-side diffing and two-window tiling.

Indentation

  • Four spaces per logic level, no tabs

Control structures

  • Use K&R bracing style: left brace at end of first line, cuddle else on both sides.

l10n labels / catalog files

  • All l10n strings are defined as delimiter-separated words using a underscore as a delimiter
  • In doubt please check the catalog files of the intranet-core package or use the messages browser: http://[YOUR_SERVER]/acs-lang/admin/message-list?package_key=intranet-core&locale=en_US 

tcl Coding Standards

equal

To compare string use 'eq/ne' instead of '==/!='

expressions

Avoid nested expressions whenever possible. 
Instead of:

set per_days [format "%0.2f" [expr $days_diff / $days * 100]

write:

set per_days [format "%0.2f" [expr ($days_diff / $days) * 100]

Database 

field types

boolean: boolean 

tbc.

  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com