Coding Style Guidelines

• 4-column indent.
• Opening curly on same line as keyword, if possible, otherwise line up.
• Space before the opening curly of a multi-line BLOCK.
• One-line BLOCK may be put on one line, including curlies.
• No space before the semicolon.
• Semicolon omitted in “short” one-line BLOCK.
• Space around most operators.
• Space around a “complex” subscript (inside brackets).
• Blank lines between chunks that do different things.
• Uncuddled elses [optional].
• No space between function name and its opening parenthesis.
• Space after each comma.
• Long lines broken after an operator (except and and or ).
• Space after last parenthesis matching on current line.
• Line up corresponding items vertically.
• Omit redundant punctuation as long as clarity doesn't suffer.
• Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem.
• While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis , especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS .
• Package names are sometimes an exception to this rule. Perl informally reserves lowercase module names for “pragma” modules like integer and strict. Other modules should begin with a capital letter and use mixed case, but probably without underscores due to limitations in primitive file systems' representations of module names as files that must fit into a few sparse bytes.
• You may find it helpful to use letter case to indicate the scope or nature of a variable. For example:

  $ALL_CAPS_HERE   constants only (beware clashes with perl vars!)
  $Some_Caps_Here  package-wide global/static
  $no_caps_here    function scope my() or local() variables

• Function and method names seem to work best as all lowercase. E.g., $obj→as_string() .
• You can use a leading underscore to indicate that a variable or function should not be used outside the package that defined it.

The complete guide can be found here perlstyle - Perl style guide

• Use an indent of 4 spaces, with no tabs.
• Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.You are strongly encouraged to always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

if ((condition1) || (condition2)) { action1; } elseif ((condition3) && (condition4)) { action2; } else { defaultaction; }   switch (condition) { case 1: action1; break;   case 2: action2; break;   default: defaultaction; break; }

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

• Function declarations follow the “BSD/Allman style”:

function fooFunction($arg1, $arg2 = '') { if (condition) { statement; } return $val; }

• Always use <?php ?> 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.

• Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter. The PEAR class hierarchy is also reflected in the class name, each level of the hierarchy separated with a single underscore. Examples of good class names are: Log Net_Finger HTML_Upload_Error
• Functions and methods should be named using the “studly caps” style (also referred to as “bumpy case” or “camel caps”). Functions should in addition have the package name as a prefix, to avoid name collisions between packages. The initial letter of the name (after the prefix) is lowercase, and each letter that starts a new “word” is capitalized. Some examples: connect() getData() buildSomeWidget() XML_RPC_serializeData()

• Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; PHP does not yet support truly-enforceable private namespaces) are preceded by a single underscore. For example: _sort() _initTree() $this→_status

• Protected class members (meaning class members that are intended to be used only from within the same class in which they are declared or from subclasses that extend it) are not preceded by a single underscore. For example: protected $somevar protected function initTree()

• Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the DB:: package all begin with DB_. Note: The true, false and null constants are excepted from the all-uppercase rule, and must always be lowercase.

• If your package needs to define global variables, their name should start with a single underscore followed by the package name and another underscore. For example, the PEAR package uses a global variable called $_PEAR_destructor_object_list.

The complete guide can be found here PEAR Coding Standards