$Id: CODING_STANDARDS.txt,v 1.3 2005/06/20 12:57:39 demian Exp $ ========================= Seagull Coding Standards ========================= Copied and slightly adapted from the Horde project Authors: Jon Parise, Chuck Hagenbuch Indenting ========= Use an indent of 4 spaces, with no tabs. Control Structures ================== These include ``if``, ``for``, ``while``, ``switch``, etc. Here is an example ``if`` statement, since it is the most complicated of them:: if ((condition1) || (condition2)) { action1; } elseif ((condition3) && (condition4)) { action2; } else { defaultaction; } Multi-line if conditions are braced this way:: if ((condition1) || (condition2) || (condition3) || (condition4)) { action1; } Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls. Do not omit the curly braces under any circumstance. ... For switch statements:: switch (condition) { case 1: action1; break; case 2: action2; break; default: defaultaction; break; } Function Calls ============== Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon. Here's an example:: $var = foo($bar, $baz, $quux); As displayed above, there should be one space on either side of an equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, more space may be inserted to promote readability:: $short = foo($bar); $longvariable = foo($baz); If assigning a reference to a variable, place the ampersand next to the referenced object, not the equal sign:: $reference = &$foo; $reference = &foo(); Function Definitions ==================== Function declaractions follow the "one true brace" convention:: function fooFunction($arg1, $arg2 = '') { if (condition) { statement; } return $val; } Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Functions used only in the current script/class (e.g. private member methods) should begin with a ``_`` character (e.g. ``_exampleLibrary``). This helps distinguish these private function calls from other, public function calls. Comments ======== Inline documentation for classes should follow the `Javadoc convention`. .. Javadoc convention: http://java.sun.com/products/jdk/javadoc/writingdoccomments/index.html Quick example for private variable definition for Seagull:: /** * Variable description. * * @var datatype $variable name */ Quick example function definition for Seagull:: /** * The description of the function goes here. * * @access [public | private] * * @param datatype $variablename Description of variable. * @param datatype $variable2name Description of variable2. * ... * [Insert 2 spaces after the longest $variable definition, and then line * up all descriptions with this description] * * @return datatype Description of return value. * [Once again, insert 2 spaces after the datatype, and line up all * subsequent lines, if any, with this character.] * * @abstract [Only if necessary] */ Including Code ============== If you are including a class, function library, or anything else which would cause a parse error if included twice, always use `include_once`. This will ensure that no matter how many factory methods we use or how much dynamic inclusion we do, the library will only be included once. If you are including a static filename, such as a conf file or a template that is *always* used, use `require`. If you are dynamically including a filename, or want the code to only be used conditionally (an optional template), use `include`. .. include_once: http://www.php.net/manual/en/function.include-once.php .. require: http://www.php.net/manual/en/function.require.php .. include: http://www.php.net/manual/en/function.include.php PHP Code Tags ============= Always use ```` to delimit PHP code, not the `` ?>`` shorthand. This is required for PEAR compliance and is also the most portable way to include PHP code on differing operating systems and setups. In templates, make sure to use this as well (````), as the shortcut version (``= $var ?>``) does not work with `short_open_tag` turned off. .. short_open_tag: http://www.php.net/manual/en/configuration.directives.php#ini.short-open-tag Header Comment Blocks ===================== TODO There's no hard rule to determine when a new code contributer should be added to the list of authors for a given source file. In general, their changes should fall into the "substantial" category (meaning somewhere around 10% to 20% of code changes). Exceptions could be made for rewriting functions or contributing new logic. Simple code reorganization or bug fixes would not justify the addition of a new individual to the list of authors. Example URLs ============ Use ``example.com`` for all example URLs, per `RFC 2606`. .. RFC 2606: http://www.faqs.org/rfcs/rfc2606.html php.ini settings ================ All Seagull code should work with `register_globals` disabled. This means using ``$COOKIE``, ``$SESSION``, ``$SERVER`` and ``$ENV`` to access all cookie, session, server and environment data, respectively. All Seagull code should work with `errorreporting` = E_ALL. Failure to do so would result in ugly output, error logs getting filled with lots of warning messages, or even downright broken scripts. XHTML 1.0 Compliance ==================== All tag names and parameters must be lower case including javascript event handlers:: ... ... All tag parameters must be of a valid parameter="value" form (numeric values must also be surrounded by quotes). For parameters that had no value in HTML, the parameter name is the value. For example::