Developers/Coding Standard

The Arcavias coding standard is based on the Zend Coding Standard. Use our cheat sheet for quick reference and an overview of the Arcavias coding standard.

File Formatting

 * PHP closing tag ?> must be omitted
 * one tab is used for one indention (no spaces!)
 * length of line should be maximal 120 characters
 * line breaks in Unix style: LF (ASCII / UTF-8 character 10 in decimal, 0x0A in hexadecimal)
 * source code is encoded in UTF-8 without byte order mark (BOM)

Eclipse Settings
These instructions are valid for Eclipse version 3.7.2 (Indigo)


 * Use tabs instead of spaces:
 * menu bar -> Window -> Preferences -> PHP -> Code Style -> Formatter -> Tab policy: Tabs
 * menu bar -> Window -> Preferences -> General -> Editors -> Text Editors -> Insert spaces for tabs: uncheck box
 * Set UTF-8 as default encoding:
 * menu bar -> Window -> Preferences -> General -> Workspace -> Text file encoding -> Other: UTF-8
 * Set line feed as default line delimiter:
 * menu bar -> Window -> Preferences -> General -> Workspace -> New text file line delimiter -> Other: Unix

Files, Classes, Interfaces

 * class names must map to the directory of the corresponding file: class  has to be defined in   (see PSR-0 standard)
 * one class per file only
 * first letter of each word is capitalized
 * the following letters should be lower case (or camel cased for specific implementation names)
 * two words have to be divided by underscore
 * names for abstract classes must end in Abstract:
 * names for interfaces must end in Interface:
 * other file names may only contain alphanumeric characters, underscores and dashes (no spaces!)

Methods, Variables and Constants

 * Only alphanumeric characters are allowed, numbers are discouraged.
 * Underscores are only allowed as prefix for private declared properties and private / protected</tt> declared method names and inside constant names.
 * private</tt> / protected</tt> methods and private</tt> properties must be prefixed by an underscore (see also visibility scope for methods and properties):


 * Names of methods and variables are written in lowerCamelCase</tt>:,   and should be as verbose as practical.
 * set</tt> and get</tt> must be used as prefixes for methods accessing properties of an object:,.
 * Constants are written in capitalized letters and multiple words are divided by underscores:

File and Class Structure

 * File, class and method documentation is mandatory.
 * The file doc block must consist of @copyright</tt>, @license</tt>, @package</tt> and @subpackage</tt>.
 * Class doc block must contain @package</tt> and @subpackage</tt>.
 * Doc blocks for methods must include @param</tt>, @return</tt> and @throws</tt>, if applicable.
 * All documentation blocks must be compatible with the phpDocumentor format (http://www.phpdoc.org).

A complete example file looks like the one below (one class per file only). All lines with <tt>//</tt> comments are only for description and must not be part of the source code.


 * Be aware of the spaces, almost everything is separated by one.
 * Exception: no space between method names and round bracket:
 * Curly brackets for classes and methods are always in their own line.
 * Class properties should be <tt>private</tt> only.
 * Methods must always declare their visibility scope with the <tt>public</tt>, <tt>protected</tt> or <tt>private</tt> keyword (see also visibility scope).
 * Type-hinting should be used whenever possible.
 * Descriptions of methods must be written in simple present.
 * Classes should declare their dependencies in one line whenever possible.

Strings and Arrays
Note: Spaces are used to separate almost everything for better readability!


 * Strings always in single quotes: !
 * Use  for every variable substitution, because it supports localization much better.


 * Numerically indexed arrays should be written in one line, if the maximum line length isn't exceeded.
 * If multiple lines are necessary, indent subsequent lines with one tab.


 * Associative arrays should be written in multiple lines.
 * Key / value pairs are indented by one tab.
 * Use a space before and after "=>" operator for associative arrays.

Control Statements
Note: Spaces are used to separate almost everything for better readability!


 * The following rules apply to all control structures where suitable, i.e. where brackets are used, like <tt>if/else</tt>, <tt>switch</tt>, <tt>while</tt>, <tt>for</tt>, <tt>foreach</tt> and <tt>try/catch</tt>.
 * Curly brackets are mandatory for all control statements.
 * Always use <tt>===</tt> operator to test for value equality, because the variable type is also considered, whereas <tt>==</tt> only tests for value equality and this can lead to bad side effects.
 * Curly brackets in if statements containing only a single line are placed in the same line as the <tt>if</tt> / <tt>else</tt> keyword.
 * The content is indented by one additional tab.
 * Closing curly brackets are aligned to the <tt>if</tt>.


 * Curly brackets in if statements containing multiple lines are always placed in an own line.
 * Content is indented by one additional tab.
 * Closing curly brackets are aligned to the <tt>if</tt>.


 * if statements with multiple test conditions resulting in long lines can occupy several lines.
 * Second and subsequent conditions are indented one tab.
 * Content is also indented by one additional tab.


 * Curly brackets for switch statements are always in an own line.
 * Case statements are indented by one additional tab.
 * Content and break statements are indented by two additional tabs.
 * The closing curly bracket is aligned to the <tt>switch</tt> keyword.

Cheat Sheet
For a quick overview our cheat sheet is perfect. It comes in two versions, one colored and the other in black/white for printing:


 * [[Media:Cheat_Sheet_colored.pdf|Cheat Sheet (colored)]]
 * [[Media:Cheat_Sheet_bw.pdf|Cheat Sheet (b/w)]]