I’ve gone through this in mantis and found its quiet simple and useful. Anyone who wishes to follow coding standard, this will be helpful for you.

Naming Variables

• 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

Naming Functions

• 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 FirstLetterOfWordIsCaptilized style
• Variables that are class objects should have the prefix coo_

Naming Files

• 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.

General Formatting

• 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

Miscellaneous

• 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.

Page Guidelines

• The first item should be the copyright notice
• At the bottom will be the footer information and closing print_ functions.

Braces and Parantheses

• Parantheses should be right after a function name, e.g. function() not function ()
• Parantheses 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
  }
  

Comparisons

• 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 ) )

Strings

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

Comments

• 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.