Software Development Guideline

We currently use the following rules, when we development software as currently defined in VWD Specification No. VWD-12 Issue C.  We have taken some of these guidelines from our own internal guidelines and listed them below. 

These guidelines must be followed. If any work is carried out on our behalf.

Software Specifications

All software developed by us, will have an internal specification no. This specification no, can be found at the bottom of the page if reporting an error or software upgrade.

This is the Virtual Web Designs coding standard document. This should assist anyone who wants to modify the code or work on active development. Anyone who wishes to contribute code must adhere to these guidelines. Code not following these conventions will be rejected.

Above all, write code that is easy to read and maintain. Comment blocks of code and functions at all times.

• Use all lower case.
• Use _ to separate words, e.g. $green_color_value
• Use descriptive names (except loop variables).
• Loop variables can be of the usual variety: $i, $j, $k, etc.
• Count variables should follow the format $*_count, e.g. $bug_count
• Global variables should be prefixed with g_
• Temporary variables should be prefixed with t_
• Parameters and variables passed from forms that have been cleaned of any special SQL chars (i.e. slashes) should be prefixed with c_
• Uncleaned function parameters should be prefixed with p_
• Uncleaned variables passed from forms should be prefixed with f_
• Other variables are prefixed with v_, v2_, etc.
• Never prefix with l_ or o_ or q_ (visually confusing)
• $query and $result should be used for SQL query and results respectively

• Use all lower case.
• Use _ to separate words, e.g. setup_page_breaks()
• Keep functions to 5 words or less
• Functions that print should be prefixed with print_.
• Try to use prefixes to group functions (i.e., email_, news_, etc.)
• Naming Classes
• Use FirstLetterOfWordIsCaptilsed style
• Variables that are class objects should have the prefix coo_

• Use all lower case.
• Use _ to separate words, e.g. view_new_bugs_page.php
• Use .php file extensions
• Filenames must be less than 32 characters in length. This plays nice with older file systems like Mac OS.
• Included files should be suffixed by _inc.php

SQL formatting

• UPPERCASE all SQL keywords:
• $query = "SELECT *
• FROM $g_mantis_bug_table
• WHERE id='1'";
• Always assign a query string to a variable. This makes code easier to debug when problems occur. Do not create the query in the call to the function.
• Break up SQL queries over multiple lines to be easy to read.

• Use TABS with a size of 4
• Follow the table formatting of existing pages
• Use <?php ?> for php delimiters.
• Try not to print/echo HTML unless it's short or in a function loop
• Do not use the EOF construct

• Don't use the ?: construct except in very rare cases. It is confusing and has a lot of bug potential.
• Avoid magic numbers. The only magic numbers in use should be 1 and 0 and their meaning should be obvious.

• The first item should be the standard header
• /*****************************************************
• ** Filename.....…...:  filename.php
• ** Package Name.....: Package Name
• ** Author..….....…..: Virtual Web Designs – Programmer Name
• ** Contact.....….…..: support@vwdesigns.co.uk
• ** Version....……....: 1.0
• ** Date .......……...: 01/01/2007
• ** Issue No.. .....:    
• ** Last Changed ....:
•  *****************************************************/
• At the bottom will be the footer information and closing print_ functions.

• Parenthesis should be right after a function name, e.g. function() not function ()
• Parenthesis should have a space right after a keyword (if, while, for), e.g. for (...)
• Formatting of braces is illustrating below. We use unmatched placing.
• Arrays should be referenced with no spaces, e.g. $arr['index'] not $arr[ 'index' ]
• for (...) {
• blah
• }
• or

• if (...) {
• blah
• }
• if ... else blocks should be in this format:
• if (...) {
• blah1
• } else {
• blah2
• }

• The NOT operator should be placed next to its operand. No spaces, e.g. !$value
• Parentheses should be used for grouping, especially with multiple comparisons, e.g. if ( ( null == $val ) && ( null == $val2 ) )

• Use spaces around the string concatenation operator, e.g. 'str ' . $value . ' str2';
• Use ' instead of " if there are no variables or special characters.

• Use the # symbol for line commenting, not //
• Use /* */ for block commenting unless you nest /* */ comments. Generally, only use this during development.
• Use @@@ followed by a brief message (BROKEN, TEMPORARY, etc) as a "look at this" indicator. Leaving your name next to is a good idea. This way critical items can easily be found.