PHP Coding Standard

Version: 1.0

Last Modified: 2003-01-11

The PHP Coding Standard is with permission based on Todd Hoff's C++ Coding Standard.
Rewritten for PHP by Fredrik Kristiansen / DB Medialab, Oslo 2000-2001.
Updated for PHP by Carl Swart, 2003.

Using this Standard. If you want to make a local copy of this standard and use it as your own you are perfectly free to do so. That's why we made it!

All credits go to the original authors. A number of changes have been made to the version dated 2002-03-04, that was available at the time of writing at the URL provided:

Before you start please verify that you have the most recent document.



Standardization is Important

It helps if the standard annoys everyone in some way so everyone feels they are on the same playing field. The proposal here has evolved over many projects, many companies, and literally a total of many weeks spent arguing. It is no particular person's style and is certainly open to local amendments.

Good Points

When a project tries to adhere to common standards a few good things happen:

Bad Points

Now the bad:


The experience of many projects leads to the conclusion that using coding standards makes the project go smoother. Are standards necessary for success? Of course not. But they help, and we need all the help we can get! Be honest, most arguments against a particular standard come from the ego. Few decisions in a reasonable standard really can be said to be technically deficient, just matters of taste. So be flexible, control the ego a bit, and remember any project is fundamentally a team effort.



The use of the word "shall" in this document requires that any project using this document must comply with the stated standard.

The use of the word "should" directs projects in tailoring a project-specific standard, in that the project must include, exclude, or tailor the requirement, as appropriate.

The use of the word "may" is similar to "should", in that it designates optional requirements.

Standards Enforcement

First, any serious concerns about the standard should be brought up and worked out within the group. Maybe the standard is not quite appropriate for your situation. It may have overlooked important issues or maybe someone in power vehemently disagrees with certain issues :-)

In any case, once finalized hopefully people will play the adult and understand that this standard is reasonable, and has been found reasonable by many other programmers, and therefore is worthy of being followed even with personal reservations.

Failing willing cooperation it can be made a requirement that this standard must be followed to pass a code inspection.

Failing that the only solution is a massive tickling party on the offending party.

Accepting an Idea

  1. It's impossible.
  2. Maybe it's possible, but it's weak and uninteresting.
  3. It is true and I told you so.
  4. I thought of it first.
  5. How could it be otherwise.
If you come to objects with a negative preconception please keep an open mind. You may still conclude objects are bunk, but there's a road you must follow to accept something different. Allow yourself to travel it for a while.


Make Names Fit

Names are the heart of programming. In the past people believed knowing someone's true name gave them magical power over that person. If you can think up the true name for something, you give yourself and the people coming after power over the code. Don't laugh!

A name is the result of a long deep thought process about the ecology it lives in. Only a programmer who understands the system as a whole can create a name that "fits" with the system. If the name is appropriate everything fits together naturally, relationships are clear, meaning is derivable, and reasoning from common human expectations works as expected.

If you find all your names could be Thing and DoIt then you should probably revisit your design.

Class Names

Method and Function Names

No All Upper Case Abbreviations



   class FluidOz             // NOT FluidOZ
   class GetHtmlStatistic       // NOT GetHTMLStatistic

Class Names



   class NameOneTwo

   class Name

Class Library Names


John Johnson's complete data structure library could use JJ as a prefix, so classes would be:
   class JjLinkList

Method Names



   class NameOneTwo
      function DoIt() {};
      function HandleError() {};

Class Attribute Names



   class NameOneTwo
      function VarAbc() {};
      function ErrorNumber() {};
      var $mVarAbc;
      var $mErrorNumber;
      var $mrName;

Method Argument Names



   class NameOneTwo
      function StartYourEngines(&$someEngine, &$anotherEngine) {
        $this->mSomeEngine = $someEngine;
        $this->mAnotherEngine = $anotherEngine;

      var $mSomeEngine;
      var $mAnotherEngine;

Variable Names



function HandleError($errorNumber)
    $error = new OsError;
    $time_of_error = $error->GetTimeOfError();
    $error_processor = $error->GetErrorProcessor();

Array Element

Array element names follow the same rules as a variable.



$myarr['foo_bar'] = 'Hello';
print "$myarr[foo_bar] world"; // will output: Hello world

$myarr['foo-bar'] = 'Hello';
print "$myarr[foo-bar] world"; // warning message

Single or Double Quotes



$myarr['foo_bar'] = 'Hello';
$element_name = 'foo_bar';
print "$myarr[foo_bar] world"; // will output: Hello world
print "$myarr[$element_name] world"; // will output: Hello world
print "$myarr['$element_name'] world"; // parse error
print "$myarr["$element_name"] world"; // parse error

Reference Variables and Functions Returning References



class Test
    var $mrStatus;
    function DoSomething(&$rStatus) {};
    function &rStatus() {};

Global Variables



    global $gLog;
    global &$grLog;

Define Names / Global Constants


It's tradition for global constants to named this way. You must be careful to not conflict with other predefined globals.


define("A_GLOBAL_CONSTANT", "Hello world!");

Static Variables



function test()
static $msStatus = 0; }

Function Names



function some_bloody_function()

Error Return Check Policy

Braces {} Policy

Of the three major brace placement strategies two are acceptable, with the first one listed being preferable:


Indentation/Tabs/Space Policy



   function func()
      if (something bad)
         if (another thing bad)
            while (more input)

Parens () with Key Words and Functions Policy



    if (condition)

    while (condition)

    strcmp($s, $s1);

    return 1;

Do Not do Real Work in Object Constructors

Do not do any real work in an object's constructor. Inside a constructor initialize variables only and/or do only actions that can't fail.

Create an Open() method for an object which completes construction. Open() should be called after object instantiation.



   class Device
      function Device()    { /* initialize and other stuff */ }
      function Open()  { return FAIL; }

   $dev = new Device;
   if (FAIL == $dev->Open()) exit(1);

Make Functions Reentrant

Functions should not keep static variables that prevent a function from being reentrant.

If Then Else Formatting


It's up to the programmer. Different bracing styles will yield slightly different looks. One common approach is:
   if (condition)                 // Comment
   else if (condition)            // Comment
   else                           // Comment
If you have else if statements then it is usually a good idea to always have an else block for finding unhandled cases. Maybe put a log message in the else even if there is no corrective action taken.

Condition Format

Always put the constant on the left hand side of an equality/inequality comparison. For example:

if ( 6 == $errorNum ) ...

One reason is that if you leave out one of the = signs, the parser will find the error for you. A second reason is that it puts the value you are looking for right up front where you can find it instead of buried at the end of your expression. It takes a little time to get used to this format, but then it really gets useful.

switch Formatting


   switch (...)
      case 1:

      case 2:
         $v = get_week_number();


Use of continue,break and ?:

Continue and Break

Continue and break are really disguised gotos so they are covered here.

Continue and break like goto should be used sparingly as they are magic in code. With a simple spell the reader is beamed to god knows where for some usually undocumented reason.

The two main problems with continue are:

Consider the following example where both problems occur:

while (TRUE)
   // A lot of code
   if (/* some condition */) {
   // A lot of code
   if ( $i++ > STOP_VALUE) break;
Note: "A lot of code" is necessary in order that the problem cannot be caught easily by the programmer.

From the above example, a further rule may be given: Mixing continue with break in the same loop is a sure way to disaster.


The trouble is people usually try and stuff too much code in between the ? and :. Here are a couple of clarity rules to follow:


   (condition) ? funct1() : func2();


      ? long statement
      : another long statement;

Alignment of Declaration Blocks



   var       $mDate
   var&      $mrDate
   var&      $mrName
   var       $mName

   $mDate    = 0;
   $mrDate   = NULL;
   $mrName   = 0;
   $mName    = NULL;

One Statement Per Line

There should be only one statement per line unless the statements are very closely related.

Short Methods


Document Null Statements

Always document a null body for a for or while statement so that it is clear that the null body is intentional and not missing code.

   while ($dest++ = $src++)
      ;         // VOID

Do Not Default If Test to Non-Zero

Do not default the test for non-zero, i.e.

   if (FAIL != f())
is better than

   if (f())
even though FAIL may have the value 0 which PHP considers to be false. An explicit test will help you out later when somebody decides that a failure return should be -1 instead of 0. Explicit comparison should be used even if the comparison value will never change; e.g., if (!($bufsize % strlen($str))) should be written instead as if (0 == ($bufsize % strlen($str))) to reflect the numeric (not boolean) nature of the test. A frequent trouble spot is using strcmp to test for string equality, where the result should never ever be defaulted.

The non-zero test is often defaulted for predicates and other functions or expressions which meet the following restrictions:

The Bull of Boolean Types

Do not check a boolean value for equality with 1 (TRUE, YES, etc.); instead test for inequality with 0 (FALSE, NO, etc.). Most functions are guaranteed to return 0 if false, but only non-zero if true. Thus,

   if (TRUE == func()) { ...
must be written

   if (FALSE != func()) { ...

Usually Avoid Embedded Assignments

There is a time and a place for embedded assignment statements. In some constructs there is no better way to accomplish the results without making the code bulkier and less readable.

   while ($a != ($c = getchar()))
      process the character

The ++ and -- operators count as assignment statements. So, for many purposes, do functions with side effects. Using embedded assignment statements to improve run-time performance is also possible. However, one should consider the tradeoff between increased speed and decreased maintainability that results when embedded assignments are used in artificial places. For example,

   $a = $b + $c;
   $d = $a + $r;
should not be replaced by

   $d = ($a = $b + $c) + $r;
even though the latter may save one cycle. In the long run the time difference between the two will decrease as the optimizer gains maturity, while the difference in ease of maintenance will increase as the human memory of what's going on in the latter piece of code begins to fade.

Reusing Your Hard Work and the Hard Work of Others

Reuse across projects is almost impossible without a common framework in place. Objects conform to the services available to them. Different projects have different service environments making object reuse difficult.

Developing a common framework takes a lot of up front design effort. When this effort is not made, for whatever reasons, there are several techniques one can use to encourage reuse:

Don't be Afraid of Small Libraries

One common enemy of reuse is people not making libraries out of their code. A reusable class may be hiding in a program directory and will never have the thrill of being shared because the programmer won't factor the class or classes into a library.

One reason for this is because people don't like making small libraries. There's something about small libraries that doesn't feel right. Get over it. The computer doesn't care how many libraries you have.

If you have code that can be reused and can't be placed in an existing library then make a new library. Libraries don't stay small for long if people are really thinking about reuse.

If you are afraid of having to update makefiles when libraries are recomposed or added then don't include libraries in your makefiles, include the idea of services. Base level makefiles define services that are each composed of a set of libraries. Higher level makefiles specify the services they want. When the libraries for a service change only the lower level makefiles will have to change.

Keep a Repository

Most companies have no idea what code they have. And most programmers still don't communicate what they have done or ask for what currently exists. The solution is to keep a repository of what's available.

In an ideal world a programmer could go to a web page, browse or search a list of packaged libraries, taking what they need. If you can set up such a system where programmers voluntarily maintain such a system, great. If you have a librarian in charge of detecting reusability, even better.

Another approach is to automatically generate a repository from the source code. This is done by using common class, method, library, and subsystem headers that can double as man pages and repository entries.

Comments on Comments

Comments Should Tell a Story

Consider your comments a story describing the system. Expect your comments to be extracted by a robot and formed into a man page. Class comments are one part of the story, method signature comments are another part of the story, method arguments another part, and method implementation yet another part. All these parts should weave together and inform someone else at another point of time just exactly what you did and why.

Document Decisions

Comments should document decisions. At every point where you had a choice of what to do place a comment describing which choice you made and why. Archeologists will find this the most useful information.

Use Headers

Use a document extraction system like phpDocumentor. Other sections in this document describe how to use phpDocumentor to document a class and method.

These headers are structured in such a way as they can be parsed and extracted. They are not useless like normal headers. So take time to fill them out. If you do it right once no more documentation may be necessary.

Comment Layout

A large part of this section is from the phpDocumentor HowTo.

phpDocumentor basics

phpDocumentor is the most advanced automatic documentation system written for PHP, in PHP.

The documentation process begins with the most basic element of phpDocumentor: a Documentation block or DocBlock. A basic DocBlock looks like this:


A DocBlock is an extended C++-style PHP comment that begins with "/**" and has an "*" at the beginning of every line. NOTE: Any line within a DocBlock that doesn't begin with a * will be ignored. DocBlocks precede the element they are documenting. To document function "foo()", type:

* Defies imagination, extends boundaries and saves the world ...all before breakfast!
function foo()

define() statements, functions, classes, class methods, and class vars can all be documented.

A DocBlock contains three basic segments in this order:

The Short Description starts on the first line, and can be terminated with a blank line or a period. A period inside a word (like or 0.1 %) is ignored. If the Short Description would become more than three lines long, only the first line is taken. The Long Description continues for as many lines as desired and may contain html markup for display formatting. Here is a sample DocBlock with a Short and a Long Description:

* return the date of Easter
* Using the formula from "Formulas that are way too complicated for anyone to 
* ever understand except for me" by Irwin Nerdy, this function calculates the 
* date of Easter given a date in the Ancient Mayan Calendar, if you can also
* guess the birthday of the author.


Tags are single words prefixed by a "@" symbol. Tags inform phpDocumentor how to present information and modify display of documentation. All tags are optional, but if you use a tag, they do have specific requirements to parse properly.

A sample DocBlock showing all possible tags

More tags may be added in the future, not all tags are implemented at this time in phpdocumentor, however they are all recognized as tags and will at least be displayed

* The short description
* As many lines of extendend description as you want {@link element} links to an element
* {@link Example hyperlink inline link} links to a website
* Below this goes the tags to further describe element you are documenting
* @param  	type	$varname	description
* @return 	type	description
* @access 	public or private
* @author 	author name <author@email>
* @copyright	name date
* @version	version
* @see		name of another element that can be documented, produces a link to it in the documentation
* @link		a url
* @since  	a version or a date
* @deprecated	description
* @deprec		alias for deprecated
* @global	type	$globalvarname
* @global	type	description of global variable usage in a function
* @staticvar	type	description of static variable usage in a function
* @name		procpagealias
* @name		$globalvaralias
* @magic compatibility
* @todo compatibility
* @exception	Javadoc-compatible, use as needed
* @throws  	Javadoc-compatible, use as needed
* @var		type	a data type for a class variable
* @package	package name
* @subpackage	sub package name, groupings inside of a project

Tag Information:

Inline Tags

Inline tags are formatted like: {@tag params}, where "tag" is the name of the inline tag and params is parameters for the inline tag. Inline tags display their output in the normal flow of the text, and should be used in descriptive areas of the DocBlock.

Elements that can be documented

Every major reusable element in PHP can be documented:

Packages are used to help you logically group related elements. You write classes to group related functions and data together, and phpDocumentor represents the contents of files (functions, defines, and includes) as "Procedural Pages." A package is used to group classes and procedural pages together in the same manner that a directory groups related files together. A Package-level doc is an html file that documents general things about an entire package. It has the name "package.html" where package is the name of the package. In other words, for package foo that contains class bar in file /php/bar.php, phpDocumentor will attempt to document "foo.html" by looking for /php/foo.html. Package-level docs should be in the same directory as any file that contains a page-level or class-level @package tag

Package-level docs should be in standard html format. The only valid tags in Package-level documentation are inline tags. For this release, that means ONLY {@link} may be used in package-level documentation

Here is some example package-level documentation for package baz that contains classes fooclass and barclass

	<title>Package baz</title>

This package is essential.  using class {@link fooclass} you can instruct your computer to brush your teeth for you.
Combining this functionality with the back massage given by {@link barclass}, you may truly retire in comfort.
In particular, {@link barclass::footmassage()} is a most exquisite experience.
Please follow this list of links for more help:
	<li><a href=""><The reinstall Windows hotline>
	<li><a href=""><Heaven>
	<li><a href=""><The phpDocumentor Homepage>
	<li><a href=""><The most beautiful music you've ever heard>


Procedural Pages are any physical files that phpDocumentor documents. They may contain any documentable element, or nothing at all, but should contain at least a page-level DocBlock to be of any use for the end-user. phpDocumentor documents all includes, defines, and functions found in the file, and links to documentation for classes defined in the file, but every class is documented separately from the physical file that contains it. In other words, if foo.php contains function bar() and class baz, bar will be documented as part of Procedural Page foo.php, and class baz will be documented as class baz. phpDocumentor interprets the first DocBlock in a file as a Procedural Page-Level DocBlock, or page-level DocBlock, if and ONLY if it does not precede any elements before the next DocBlock.

* Page-level DocBlock
* This procedural page contains many functions that blah blah blah
* function or define DocBlock
function blah()

The following is an example of a NON-page-level DocBlock

* Almost a Page-level DocBlock
* This procedural page contains many functions that blah blah blah
* function or define DocBlock
function blah()

phpDocumentor will interpret the first DocBlock as belonging to define("screwedup",66)rather than to the page

Global Variables can only be documented by using the @global tag in a DocBlock preceding the global variable's definition. See the manual for @global for detailed information on how to use @global to document your project's global variables.

All other elements are documented by placing the DocBlock before the element. Any valid PHP Code may be placed between a DocBlock and an element as long as it isn't another element.

* DocBlock will document function blah()
// random comment
$a += strpos(get_another_thingy(66,$ufta));
// etc. etc.
function blah()

A Simple Example

The code below is a sample class showing phpDocumentor in action

phpDocumentor can parse any valid PHP code, but it is recommended to follow this style for ease of programming for both you and people who will be using your packages

* A sample page-level DocBlock
* The package tag applies to all global variables, functions, defines and includes in this page
* @package pagetest
* A sample global variable
* @global array $GLOBALS['sample']
* @name $sample
$GLOBALS['sample'] = array('1',2,"3","4" => 5);
* A sample class
* This class is just random php used as a {@link phpdoc} example.
* To see the $sample variable, you must use the command-line option --parseprivate or click the
* box in the web interface
* @version 1.0
* @author Joshua Eichorn <>
* @package test
class phptestclass
	* not parsed unless you use -pp on
	* @access private
	var $privatevar;
	* A sample class variable
	* @var string
	var $sample;

	* The class constructor
	* This sets up the class and does other random stuff
	function phptestclass()
		$this->sample = "test";

	* A test function
	* This function returns {@link $sample}
	* @see set(), $sample
	* @global array used to get some sample stuff
	* @return string
	function test()
		global $sample;
		return $sample == $this->sample;

	* Set the sample var
	* @param string $var
	* @see phptestclass::$sample, phptestclass::test()
	function set($var)
		$this->sample = $var;

* This function is in the page package, which is "pagetest" and not "ignored"
* this @package tag is ignored - only the page-level tag is parsed.
* @staticvar phptestclass an example of our static documentation
* @package ignored
function inPagePackage()
	static $mememe;
	$mememe = new phptestclass;

Make Gotchas Explicit

Explicitly comment variables changed out of the normal control flow or other code likely to break during maintenance. Embedded keywords are used to point out issues and potential problems. Consider a robot will parse your comments looking for keywords, stripping them out, and making a report so people can make a special effort where needed.

Gotcha Keywords

Gotcha Formatting


   // :TODO: tmh 960810: possible performance problem
   // We should really use a hash table here but for now we'll
   // use a linear search.

   // :KLUDGE: tmh 960810: possible unsafe type cast
   // We need a cast here to recover the derived type. It should
   // probably use a virtual method or template.

See Also

See Interface and Implementation Documentation for more details on how documentation should be laid out.

Interface and Implementation Documentation

There are two main audiences for documentation: With a little forethought we can extract both types of documentation directly from source code.

Class Users

Class users need class interface information which when structured correctly can be extracted directly from a header file. When filling out the header comment blocks for a class, only include information needed by programmers who use the class. Don't delve into algorithm implementation details unless the details are needed by a user of the class. Consider comments in a header file a man page in waiting.

Class Implementors

Class implementors require in-depth knowledge of how a class is implemented. This comment type is found in the source file(s) implementing a class. Don't worry about interface issues. Header comment blocks in a source file should cover algorithm issues and other design decisions. Comment blocks within a method's implementation should explain even more.

Directory Documentation

Every directory should have a README file that covers: Consider a new person coming in 6 months after every original person on a project has gone. That lone scared explorer should be able to piece together a picture of the whole project by traversing a source directory tree and reading README files, Makefiles, and source file headers.

Open/Closed Principle

The Open/Closed principle states a class must be open and closed where: The Open/Closed principle is a pitch for stability. A system is extended by adding new code not by changing already working code. Programmers often don't feel comfortable changing old code because it works! This principle just gives you an academic sounding justification for your fears :-)

In practice the Open/Closed principle simply means making good use of our old friends abstraction and polymorphism. Abstraction to factor out common processes and ideas. Inheritance to create an interface that must be adhered to by derived classes.

Server configuration

This section contains some guidelines for PHP/Apache configuration.


HTTP_*_VARS are either enabled or disabled. When enabled all variables must be accessed through $HTTP_*_VARS[key]. When disabled all variables can be accessed by the key name.


PHP File Extensions

There is lots of different extension variants on PHP files (.html, .php, .php3, .php4, .phtml, .inc, .class...).



This section contains some miscellaneous do's and don'ts.

Use if (0) to Comment Out Code Blocks

Sometimes large blocks of code need to be commented out for testing. The easiest way to do this is with an if (0) block:
   function example()
      great looking code

      if (0) {
      lots of code

      more code

You can't use /**/ style comments because comments can't contain comments and surely a large block of your code will contain a comment, won't it?

Different Accessor Styles

Implementing Accessors

There are two major idioms for creating accessors.


   class X
      function GetAge()        { return $this->mAge; }
      function SetAge($age)    { $this->mAge = $age; }
      var $mAge;
Get/Set is ugly. Get and Set are strewn throughout the code cluttering it up.

But one benefit is when used with messages the set method can transparently transform from native machine representations to network byte order.

Attributes as Objects

   class X
      function         Age()          { return $this->mAge; }
      function         Name()         { return $this->mName; }

      var              $mAge;
      var              $mName;

   $x = new X;

   // Example 1
   $age = $x->Age();
   $r_age = &$x->Age(); // Reference

   // Example 2
   $name = $x->Name();
   $r_name = &$x->Name(); // Reference
Attributes as Objects is clean from a name perspective. When possible use this approach to attribute access.


Layering is the primary technique for reducing complexity in a system. A system should be divided into layers. Layers should communicate between adjacent layers using well defined interfaces. When a layer uses a non-adjacent layer then a layering violation has occurred.

A layering violation simply means we have dependency between layers that is not controlled by a well defined interface. When one of the layers changes code could break. We don't want code to break so we want layers to work only with other adjacent layers.

Sometimes we need to jump layers for performance reasons. This is fine, but we should know we are doing it and document appropriately.

Code Reviews

If you can make a formal code review work then my hat is off to you. Code reviews can be very useful. Unfortunately they often degrade into nit picking sessions and endless arguments about silly things. They also tend to take a lot of people's time for a questionable payback.

My god he's questioning code reviews, he's not an engineer!

Not really, it's the form of code reviews and how they fit into normally late chaotic projects is what is being questioned.

First, code reviews are way too late to do much of anything useful. What needs reviewing are requirements and design. This is where you will get more bang for the buck.

Get all relevant people in a room. Lock them in. Go over the class design and requirements until the former is good and the latter is being met. Having all the relevant people in the room makes this process a deep fruitful one as questions can be immediately answered and issues immediately explored. Usually only a couple of such meetings are necessary.

If the above process is done well coding will take care of itself. If you find problems in the code review the best you can usually do is a rewrite after someone has sunk a ton of time and effort into making the code "work."

You will still want to do a code review, just do it offline. Have a couple people you trust read the code in question and simply make comments to the programmer. Then the programmer and reviewers can discuss issues and work them out. Email and quick pointed discussions work well. This approach meets the goals and doesn't take the time of 6 people to do it.

Create a Source Code Control System Early and Not Often

A common build system and source code control system should be put in place as early as possible in a project's lifecycle, preferably before anyone starts coding. Source code control is the structural glue binding a project together. If programmers can't easily use each other's products then you'll never be able to make a good reproducible build and people will piss away a lot of time. It's also hell converting rogue build environments to a standard system. But it seems the right of passage for every project to build their own custom environment that never quite works right.

Some issues to keep in mind:


If you have the money many projects have found Clear Case a good system. Perfectly workable systems have been built on top of GNU make and CVS. CVS is a freeware build environment built on top of RCS. Its main difference from RCS is that is supports a shared file model to building software.

Create a Bug Tracking System Early and Not Often

The earlier people get used to using a bug tracking system the better. If you are 3/4 through a project and then install a bug tracking system it won't be used. You need to install a bug tracking system early so people will use it.

Programmers generally resist bug tracking, yet when used correctly it can really help a project:

Not sexy things, just good solid project improvements.

Source code control should be linked to the bug tracking system. During the part of a project where source is frozen before a release only checkins accompanied by a valid bug ID should be accepted. And when code is changed to fix a bug the bug ID should be included in the checkin comments.


You can try for bug tracking.

Honor Responsibilities

Responsibility for software modules is scoped. Modules are either the responsibility of a particular person or are common. Honor this division of responsibility. Don't go changing things that aren't your responsibility to change. Only mistakes and hard feelings will result.

Face it, if you don't own a piece of code you can't possibly be in a position to change it. There's too much context. Assumptions seemingly reasonable to you may be totally wrong. If you need a change simply ask the responsible person to change it. Or ask them if it is OK to make such-n-such a change. If they say OK then go ahead, otherwise holster your editor.

Every rule has exceptions. If it's 3 in the morning and you need to make a change to make a deliverable then you have to do it. If someone is on vacation and no one has been assigned their module then you have to do it. If you make changes in other people's code try and use the same style they have adopted.

Programmers need to mark with comments code that is particularly sensitive to change. If code in one area requires changes to code in an another area then say so. If changing data formats will cause conflicts with persistent stores or remote message sending then say so. If you are trying to minimize memory usage or achieve some other end then say so. Not everyone is as brilliant as you.

The worst sin is to flit through the system changing bits of code to match your coding style. If someone isn't coding to the standards then ask them or ask your manager to ask them to code to the standards. Use common courtesy.

Code with common responsibility should be treated with care. Resist making radical changes as the conflicts will be hard to resolve. Put comments in the file on how the file should be extended so everyone will follow the same rules. Try and use a common structure in all common files so people don't have to guess on where to find things and how to make changes. Checkin changes as soon as possible so conflicts don't build up.

As an aside, module responsibilities must also be assigned for bug tracking purposes.

PHP Code Tags

PHP Tags are used for delimit PHP from html in a file. There are serval ways to do this. <?php ?>, <? ?>, <script language="php"> </script>, <% %>, and <?=$name?>. Some of these may be turned off in your PHP settings.



<?php print "Hello world"; ?> // Will print "Hello world"

<? print "Hello world"; ?> // Will print "Hello world"

<script language="php"> print "Hello world"; </script> // Will print "Hello world"

<% print "Hello world"; %> // Will print "Hello world"

<?=$street?> // Will print the value of the variable $street

No Magic Numbers

A magic number is a bare-naked number used in source code. It's magic because no-one has a clue what it means including the author inside 3 months. For example:

if      (22 == $foo) { start_thermo_nuclear_war(); }
else if (19 == $foo) { refund_lotso_money(); }
else if (16 == $foo) { infinite_loop(); }
else                 { cry_cause_im_lost(); }
In the above example what do 22 and 19 mean? If there was a number change or the numbers were just plain wrong how would you know?

Heavy use of magic numbers marks a programmer as an amateur more than anything else. Such a programmer has never worked in a team environment or has had to maintain code or they would never do such a thing.

Instead of magic numbers use a real name that means something. You should use define(). For example:

define("PRESIDENT_WENT_CRAZY", "22");
define("WE_GOOFED", "19");
define("THEY_DIDNT_PAY", "16");

if      (PRESIDENT_WENT_CRAZY == $foo) { start_thermo_nuclear_war(); }
else if (WE_GOOFED            == $foo) { refund_lotso_money(); }
else if (THEY_DIDNT_PAY       == $foo) { infinite_loop(); }
else                                   { happy_days_i_know_why_im_here(); }
Now isn't that better?

Thin vs. Fat Class Interfaces

How many methods should an object have? The right answer of course is just the right amount, we'll call this the Goldilocks level. But what is the Goldilocks level? It doesn't exist. You need to make the right judgment for your situation, which is really what programmers are for :-)

The two extremes are thin classes versus thick classes. Thin classes are minimalist classes. Thin classes have as few methods as possible. The expectation is users will derive their own class from the thin class adding any needed methods.

While thin classes may seem "clean" they really aren't. You can't do much with a thin class. Its main purpose is setting up a type. Since thin classes have so little functionality many programmers in a project will create derived classes with everyone adding basically the same methods. This leads to code duplication and maintenance problems which is part of the reason we use objects in the first place. The obvious solution is to push methods up to the base class. Push enough methods up to the base class and you get thick classes.

Thick classes have a lot of methods. If you can think of it a thick class will have it. Why is this a problem? It may not be. If the methods are directly related to the class then there's no real problem with the class containing them. The problem is people get lazy and start adding methods to a class that are related to the class in some willow wispy way, but would be better factored out into another class. Judgment comes into play again.

Thick classes have other problems. As classes get larger they may become harder to understand. They also become harder to debug as interactions become less predictable. And when a method is changed that you don't use or care about your code will still have to be retested, and rereleased.

Recent Changes

  1. 2003-01-11. Rewritten the Comments section, to be phpDocumentor (JAVADoc) Compatible. Added a version number and a history.
  2. 2002-03-04. Some changes in PHP File Extensions section. Only .php extensions is now recommended.
  3. 2002-01-23. I've added Array Element.
  4. 2001-08-13. The Variable Names example is now compatible with this PHP standard. Added word version of this document submitted by Chris Hubbard.
  5. 2001-01-23. Method Argument Names example code fix. Parts of Different Accessor Styles has been deprecated because there was no support in PHP for these.
  6. 2000-12-12. HTTP_*_VARS added
  7. 2000-12-11. Indentation/Tabs/Space Policy has been changed
    PHP Code Tags added
  8. 2000-12-05. Method Argument Names has been updated


  1. 2003-01-11. Version 1.0 Released.

© Copyright 1995-2002. Todd Hoff and Fredrik Kristiansen. All rights reserved.
© Copyright 2003. Carl Swart. All rights reserved.