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
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++;
}
- 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.
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 So, my only real fashion gripe is
with this one:
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
>
> 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