[livesupport-dev] PHP Coding Standards: Draft v0.1
  • Here is the draft specification that we(Mugur, Akos, Paul) came up with
    during Summercamp. Please review and post your comments. (Please
    cross-post to both lists when you reply)

    GENERAL FORMATTING
    ------------------
    Use a tab of four (4) characters, and set your editor to insert spaces
    instead of tabs.
    REASON: This will align the code correctly when you email around code
    snippets, or otherwise export the code.

    Use full " REASON: The php.ini file may not have short_tags turned on.

    Limit the number of characters per line between 80-100 characters.


    ALL FUNCTION DEFINITIONS
    ------------------------
    Function declarations follow the "one true brace" convention.

    Example:
    function fooFunction($p_arg1, $p_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 that return boolean values should work well (grammatically) in
    an IF statement.

    Example:
    Bad: function FigureOutIfValid() { }
    Good: function IsValid() { }


    STATIC FUNCTION DEFINITIONS
    ---------------------------
    Static (global) function names should have the prefix "camp_".
    REASON: You will be able to tell the difference between built-in
    functions and campware functions.
    Example: camp_run();

    Static function names should use lower case letters and separate words
    with an underscore.
    REASON: This is how built-in static function calls in PHP are written.
    Example:
    camp_array_get_value();


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

    Example:
    $var = camp_foo($bar, $baz, $quux);


    VARIABLES
    ---------
    Prefixes for variable names:
    Global: "g_"
    Parameter: "p_"
    Member variable: "m_"
    Form variable: "f_"
    REASON: So you can easily tell where a variable is from.

    Example:
    global $g_config;
    class Input {
    var $m_count;

    function process($p_request) {
    $tmp = $p_request["f_name"];
    if (!empty($tmp)) {
    $this->m_count++;
    }
    } // fn process

    } // class Input


    CLASSES
    -------
    Capitalize the name of each word in a class name.
    Example:
    class MyClassName { }

    The file name should match the class name with ".php" at the end.
    There should be one class per file, unless there are performance
    considerations to take into account.
    Example:
    MyClassName.php


    MEMBER FUNCTIONS
    ----------------
    Member functions names begin with a lowercase letter and otherwise
    follow the same conventions as class names.


    STATIC MEMBER FUNCTIONS
    -----------------------
    Static member function names start with an uppercase character and begin
    each word with a capital letter, just like class names. This only
    applies to functions that are exclusively static, and not functions that
    can also be called as member functions.


    COMMENTS
    --------
    Don't use "#" for comments.
    REASON: Consistent look for comments, and rumors of deprecating "#".

    Use PHPDocumentor (http://www.phpdoc.org/) conventions to comment the
    code.
    REASON: It's the most advanced PHP documentation system that exists.
    PHPDoc is way behind (uses 'grep' to parse instead of a parsing engine),
    and Doxygen does not fully support PHP.

    Example:
    /**
    * This function adds 1 to the given parameter.
    *
    * Long Description Goes here...take the variable p_value,
    * and apply the addition operator ('+'), thereby increasing
    * the original value by one (1). This is also known as
    * 'incrementing' a variable. As an example, you could use this
    * operation in a loop when you know how many times you have
    * to iterate.
    *
    * @param int p_value
    * @return int
    */
    function addOne($p_value) {
    return $p_value++;
    } // fn addOne

    See the manual here:
    http://manual.phpdoc.org/HTMLframesConverter/DOM/default/


    ASSIGNMENT
    ----------
    Use spaces around assignments and between operators:
    $a = 5;
    $b = $a + 4;
    REASON: Easy to read.


    SQL
    ---
    In SQL statements, capitalize keywords.
    REASON: easy distinction between keywords and non-keywords.


    CONTROL STRUCTURES (IF, WHILE, DO, SWITCH, FOR, FOREACH)
    --------------------------------------------------------
    - Always use braces, even for single statements. REASON: prevent bugs
    during maintenance, readability.
    Example:
    if ($x == 0) {
    $x++;
    }

    - Always parenthesis boolean expressions.
    Example:
    if ( ($x == 0) || ($y == 0)) { }

    - Control statements should have one space between the control keyword
    and opening parenthesis, to distinguish them from function calls.
    Example:
    if (true) { }

    - Always explicitly state what you are checking for in a boolean
    expression. REASON: This helps others to know what you are checking for.
    Example:
    Instead of:
    if ($x) { }
    do:
    if (!empty($x)) { }
    or:
    if ($x == 0) { }

    - Use space characters to separate tokens as in the following examples.

    IF STATEMENTS
    -------------

    Examples:
    if ( ($x == 0) || ($y == 0) ) {
    $x = 1;
    } else {
    $x = 2;
    }

    $a = $b ? $c : $d;


    SWITCH
    ------
    switch ($foo) {
    case 1:
    $x = $x + 1;
    break;
    case 2:
    $x = $x - 1;
    break;
    }

    FOR
    ---
    for ($i = 0; $i < 10; $i++) {
    echo $i;
    }

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • 4 Comments sorted by
  • Hi Paul, Mugur, Akos,

    Sorry that I couldn't get online and chat with you guys last week. Doug
    and I tried to get it working, but it just didn't work out. Alas.
    Anyway, I just read your codings standard and happily I agree with
    almost all of it, which is pretty good, since all this amounts to a
    coder's "dress sense", doesn't it Wink So, my only real fashion gripe is
    with this one:

    Paul Baranowski wrote:

    >VARIABLES
    >---------
    >Prefixes for variable names:
    >Global: "g_"
    >Parameter: "p_"
    >Member variable: "m_"
    >Form variable: "f_"
    >REASON: So you can easily tell where a variable is from.
    >
    >
    I think that this is a insidious Microsoft practise t must be stamped out!
    http://www.worldwidewords.org/articles/hungary.htm
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconcodingconventionsoverview.asp
    http://ootips.org/hungarian-notation.html

    The far more prevalent PHP coding conventions, as used in PEAR, ADODB,
    SimpleTest, JPSPAN, etc etc, are more along the lines of:

    * CONSTANTS
    * $parameters
    * $object->memberVariable or $object->member_variable (prefixed with
    _ if private)
    * $object->memberFunction() (prefixed with _ if private)
    * $GLOBALS (although one should never need them, right?)

    Furthermore, I'd be against prefixing form variables with 'f_' as it
    needlessly clutters up your HTML and furthermore introduces extra
    hassles when working with DB abstraction layers and form handling
    routines like QuickForm.

    Any chance you would reconsider this one item?

    Cheers

    JP

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • John Pye wrote:
    > I think that this is a insidious Microsoft practise t must be stamped out!
    > http://www.worldwidewords.org/articles/hungary.htm
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconcodingconventionsoverview.asp
    >
    > http://ootips.org/hungarian-notation.html

    yes, this is a point I regret to be hungarian Smile

    >
    > The far more prevalent PHP coding conventions, as used in PEAR, ADODB,
    > SimpleTest, JPSPAN, etc etc, are more along the lines of:
    >
    > * CONSTANTS
    > * $parameters
    > * $object->memberVariable or $object->member_variable (prefixed with
    > _ if private)
    > * $object->memberFunction() (prefixed with _ if private)
    > * $GLOBALS (although one should never need them, right?)
    >
    > Furthermore, I'd be against prefixing form variables with 'f_' as it
    > needlessly clutters up your HTML and furthermore introduces extra
    > hassles when working with DB abstraction layers and form handling
    > routines like QuickForm.
    >
    > Any chance you would reconsider this one item?

    I aggree with John here...


    Akos

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • John Pye wrote:
    > Paul Baranowski wrote:
    >
    >> VARIABLES
    >> ---------
    >> Prefixes for variable names:
    >> Global: "g_"
    >> Parameter: "p_"
    >> Member variable: "m_"
    >> Form variable: "f_"
    >> REASON: So you can easily tell where a variable is from.
    >>
    > I think that this is a insidious Microsoft practise t must be stamped out!
    > [snip]

    Dont worry...its not hungarian notation. We are only indicating scope,
    and not type. I've found this incredibly useful when reading functions
    because I know when looking at the code whether something is an input to
    the function, member variable, or global. In your examples below, there
    is no distinction between parameters and local variables. The "f_" can
    be optional if there is a technical reason not to use it as you pointed
    out.

    > The far more prevalent PHP coding conventions, as used in PEAR, ADODB,
    > SimpleTest, JPSPAN, etc etc, are more along the lines of:
    >
    > * CONSTANTS

    Forgot to put this one in there...oops.

    > * $object->memberVariable or $object->member_variable (prefixed with
    > _ if private)

    99.999% of all member variables will be private (so far 100%), so we
    would be using an "_" anyway for every member variable. Adding a "m" to
    the front distinguishes it from a private function (which is important
    if you use Zend so that it can auto-complete variable and function names
    for you).

    - Paul

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Paul Baranowski wrote:
    >> * $object->memberVariable or $object->member_variable (prefixed with
    >> _ if private)
    >
    >
    > 99.999% of all member variables will be private (so far 100%), so we
    > would be using an "_" anyway for every member variable. Adding a "m" to
    > the front distinguishes it from a private function (which is important

    I have to disaggree here. AFAIK in PHP (as in C and C++),
    differentiating betweek data instances and function calls is not
    context-sensitive: a funciton call is always followed by parenthesis. in
    this case, there is already a distinction between variables and functions.

    or am I wrong? can one call a function with only it's name:

    function;

    instead of:

    function();

    ?

    ------------------------------------------
    Posted to Phorum via PhorumMail