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

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

E-08907 Hospitalet de Llobregat (Barcelona)

 Tel Europe: +34 932 202 088
 Tel US: +1 415 429 5995
 Mail: info@project-open.com