Actions

Difference between revisions of "Developer Area/Coding guidelines"

From Mahara Wiki

< Developer Area
m (Reverted edits by Aaronw (Talk) to last revision by Hughdavenport)
(Undo revision 4328 by Aaronw (Talk))
Line 23: Line 23:
 
=Comments=
 
=Comments=
  
Comments of up to three lines in length should use the // comment marker. Comments longer than three lines should use /* ... */. Here is an example comment:
+
Comments at the head of files, functions, classes, etc should use the /** ... */ comment form for compatibility with [http://en.wikipedia.org/wiki/PHPDoc PHPDoc]. Explanatory comments in the body of the code should use only // comment markers, regardless of the length of the comment. (This allows /* ... */ markers to be used for quick mass commenting during debugging.) Comments about a line of code should be placed on their own line above that line of code, rather than at the end of it.
  
<div class="plugin tightenable"><code><font color="#000000"> <font color="#ff8000">/*<br />    This part is difficult, and requires a long<br />    explanation. This is that explanation. I am<br />    still typing to see if I can make it to four<br />    lines.<br /> */<br /></font> </font> </code></div>
+
Example:
 
 
Please note that the opening and ending markers are on their own lines - nothing else should be on these lines.
 
  
 +
/**
 +
  * This is an explanation of what this function does.
 +
  *
 +
  * @param boolean $bar description of the purpose of $bar
 +
  * @param string $baz description of the purpose of $baz
 +
  * @param array $qux description of the purpose of $qux
 +
  * @return array|string This function either returns $qux with $baz added to it, or $baz with $bar added to it
 +
  */
 +
function foo($bar, $baz='bax', $qux=array()) {
 +
   
 +
    // This part is difficult and requires a long
 +
    // explanation. This is that explanation. I am
 +
    // still typing to see if I can make it to four
 +
    // lines.
 +
    if ($bar) {
 +
       
 +
        // put it on the end
 +
        $qux[] = $baz;
 +
        return $qux;
 +
    } else {
 +
       
 +
        // I'm sure this makes sense somehow
 +
        return $baz || ((string) $bar);
 +
    }
 +
}
  
 
=Language Constructs=
 
=Language Constructs=
Line 42: Line 65:
 
These statements should have brackets around the argument. There is no space between the statement and the bracket. In effect, this is the same as a function call.
 
These statements should have brackets around the argument. There is no space between the statement and the bracket. In effect, this is the same as a function call.
  
<div class="plugin tightenable"><code><font color="#000000"> <font color="#007700">require_once(</font><font color="#dd0000">'my/file.php'</font><font color="#007700">);<br /></font> </font> </code></div>
+
Except for the initial require/require_once for init.php, all calls to these functions should use absolute file paths, based on <code>get_config('dirroot')</code> or some other config variable. The call to init.php should be made using multiple calls to <code>dirname(__FILE__)</code> to generate an absolute path based on the location of the current script file, rather than a relative path using "../..".
 +
 
 +
require(dirname(dirname(__FILE__)) . '/init.php');
 +
require_once(get_config('libroot') . 'view.php');
 +
require_once(get_config('dirroot') . 'local/lib.php');
  
 
'''NOT''':
 
'''NOT''':
  
<div class="plugin tightenable"><code><font color="#000000"> <font color="#007700">require_once </font><font color="#dd0000">'my/file.php'</font><font color="#007700">;<br /> require_once (</font><font color="#dd0000">'my/file.php'</font><font color="#007700">);<br /></font> </font> </code></div>
+
require('../../init.php');
 +
require_once 'view.php';
 +
require_once ('local/lib.php');
  
Plugin files '''must''' be included using the [http://mahara.eduforge.org/api/mahara/core/_lib---mahara.php.html#functionsafe_require <span style="white-space: nowrap">[[Image:http.png]]safe_require</span>] function. This function ensures that there are no vulnerabilities in accessing a plugin file. Plugins that do not use this function to include files should be considered vulnerable to a possible security vulnerability.
+
Plugin files '''must''' be included using the '''<code>safe_require()</code>''' function. This function ensures that there are no vulnerabilities in accessing a plugin file. Plugins that do not use this function to include files should be considered vulnerable to a possible security vulnerability.
  
 
Any include statements in the core should '''never''' have a variable in their name, to reduce the chance of an arbitary include vulnerability.
 
Any include statements in the core should '''never''' have a variable in their name, to reduce the chance of an arbitary include vulnerability.
Line 68: Line 97:
 
What should be '''never''' used:
 
What should be '''never''' used:
  
<div class="plugin tightenable"><code><font color="#000000"> <font color="#ff8000">// For a really short condition<br /></font><font color="#007700">if (</font><font color="#0000bb">$a </font><font color="#007700">== </font><font color="#0000bb">$b</font><font color="#007700">) </font><font color="#0000bb">$c </font><font color="#007700">= </font><font color="#0000bb">1</font><font color="#007700">;<br /><br /></font><font color="#ff8000">// Just don't. Not even ow.<br /></font><font color="#007700">do {<br />     echo </font><font color="#dd0000">'hi'</font><font color="#007700">;<br /> } while (</font><font color="#0000bb">$a </font><font color="#007700">== </font><font color="#0000bb">1</font><font color="#007700">);<br /></font> </font> </code></div><div id="section_7">
+
<div class="plugin tightenable"><code><font color="#000000"> <font color="#ff8000">// For a really short condition<br /></font><font color="#007700">if (</font><font color="#0000bb">$a </font><font color="#007700">== </font><font color="#0000bb">$b</font><font color="#007700">) </font><font color="#0000bb">$c </font><font color="#007700">= </font><font color="#0000bb">1</font><font color="#007700">;<br /><br /></font> </font> </code></div><div id="section_7">
  
 
==Variables and Arrays==
 
==Variables and Arrays==

Revision as of 11:52, 26 April 2013

This page documents the coding conventions used by Mahara. Everything that ends up in the git repository (other than third-party code) should follow these standards.

You can also have a look at the Reviewer's manual to see what reviewers will look at when looking at code submissions.

PHP Files

JavaScript Files (or snippets)

CSS Files

SQL snippets

XML Files

TPL Files (may change in future if move away from smarty, ie to twig)

The Basics

All files must adhere to the BasicPHPFileTemplates. There are slightly different templates depending on whether the script is to be included or whether it is to be directly hit.

Indentation is using four (4) spaces. There is no requirement that the scripts are wrapped at 80 columns, however developers are asked to wrap long lines sensibly.

Comments

Comments at the head of files, functions, classes, etc should use the /** ... */ comment form for compatibility with PHPDoc. Explanatory comments in the body of the code should use only // comment markers, regardless of the length of the comment. (This allows /* ... */ markers to be used for quick mass commenting during debugging.) Comments about a line of code should be placed on their own line above that line of code, rather than at the end of it.

Example:

/**
 * This is an explanation of what this function does.
 *
 * @param boolean $bar description of the purpose of $bar
 * @param string $baz description of the purpose of $baz
 * @param array $qux description of the purpose of $qux
 * @return array|string This function either returns $qux with $baz added to it, or $baz with $bar added to it
 */
function foo($bar, $baz='bax', $qux=array()) {
    
    // This part is difficult and requires a long
    // explanation. This is that explanation. I am
    // still typing to see if I can make it to four
    // lines.
    if ($bar) {
        
        // put it on the end
        $qux[] = $baz;
        return $qux;
    } else {
        
        // I'm sure this makes sense somehow
        return $baz || ((string) $bar);
    }
}

Language Constructs

Strings

Strings should be quoted with single quotes (') unless you are interpolating a variable.


require/require_once/include/include_once

These statements should have brackets around the argument. There is no space between the statement and the bracket. In effect, this is the same as a function call.

Except for the initial require/require_once for init.php, all calls to these functions should use absolute file paths, based on get_config('dirroot') or some other config variable. The call to init.php should be made using multiple calls to dirname(__FILE__) to generate an absolute path based on the location of the current script file, rather than a relative path using "../..".

require(dirname(dirname(__FILE__)) . '/init.php');
require_once(get_config('libroot') . 'view.php');
require_once(get_config('dirroot') . 'local/lib.php');

NOT:

require('../../init.php');
require_once 'view.php';
require_once ('local/lib.php');

Plugin files must be included using the safe_require() function. This function ensures that there are no vulnerabilities in accessing a plugin file. Plugins that do not use this function to include files should be considered vulnerable to a possible security vulnerability.

Any include statements in the core should never have a variable in their name, to reduce the chance of an arbitary include vulnerability.

The include path is set automatically to be the current directory plus the lib directory - there is no need to specify an absolute directory path.

if/while/for statements

There is one space after each language construct, and no spaces between brackets and the arguments inside them, unless what is inside them becomes too long for one line, in which case a special format will be used.

Examples of what is good:

if (1 == 2) {
    die(
'omg');
}

while (
$i < 3) {
    echo
'I am ' . $i;
}

for (
$i = 0, $j = 7; $i < 34, $j != 3; $i++, $j--) {
    echo (
$i * $j) . ' is a silly number';
}

// Note bracing style of else if/else clauses
// Also note: do not use elseif
if ($a == $b) {
    echo
"a = b";
}
else if (
$c == $d) {
    echo
"c = d";
}
else {
    echo
"e = ?";
}

// Ternary operator
$a = ($b == true) ? 'hello' : 'goodbye';
// When used with other things on each side in the same statement:
$a = 'foo' . (($b == true) ? 'hello' : 'goodbye') . 'bar';

// A complicated condition. Note location of condition,
// and location of ending bracket and brace.
// todo: what was the decision here regarding conditions on the "if (" line?
if (
    
$sacrificedgoats == $availablegoats
    
&& ($dogs == $cats
    
|| 1 != 2)
    || (
$yesterday >> $tomorrow == 4)
) {
    
// Do stuff
}

Examples of what is bad:

if ( $a == $b )
{
    echo
'hi';
}

if(
$c == $d) {
    echo
'hi';
} else {
    echo
'bye';
}

if (
$e==$f)
{
    echo
'hi';
}
else
{
    echo
'bye';
}

What should be never used:

// For a really short condition
if ($a == $b) $c = 1;

Variables and Arrays

Variables should be named with no underscores, and no capital letters. This policy may become more lenient in future if variable names are discovered that are not easily readable without underscores.

Do not name variables as negatives where possible - always use positive names and logical inversion (!) where required.

Hungarian notation is forbidden.

When related variables are initialised, the = signs for them should line up. Other than that, aligning = signs for variable assignment is up to the developer, although they should use common sense in such decisions.

Good:

$found = false;
$ponies = 0;
$servername = $overkill;

// Only in relation to controlling for/while loops
for ($i = 10; $i > 5; $i--) {
    echo
$i;
}

// Aligning = signs
$mine   = 0;
$yours  = 0;
$theirs = 0;

// Only if the number of elements to initialise is small.
$array = array(1 => 'hello');

// If large number of elements to initialise:
$array = array(
    
1  => 'hello',
    
2  => 'goodbye',
    
10 => 'erm'
);

Bad:

// Negative name
$notfound = true;
// Underscores
$my_variable = '';
// Hungarian. Eew....
$count_i = 6;
// Uppercase letters
$myFish = $yourFish;

// Not necessarily "bad", just not for this project
$array = array(
                
1 => 'hello',
                
2 => 'goodbye',
                
10 => 'erm'
              
);

Binary Operators

Always have a space on each side:

echo 1 + 2;
if (
1 == 2)
echo
'hello' . ' world';

|| and && will always be used for 'or' and 'and' respectively. Resolve priority collisions with extra brackets as required.

Classes, Functions and Methods

Nameing

Classes should start with upper case character, then each word capitalized.

ExampleWhizbang

Functions should not use camel case, and instead use underscores as word seperators

do_something()

NOT

doSomething()

Declaration:

/**
* PHPDoc comment describing the function
*
* Note how the default value has no spaces
*/
function foo($a, Class $b, $c='') {
    
// source
    
return $value;
}

class
FooBar extends Bar {

    
/**
     * PHPDoc for the field
     *
     * For this project, do not use doThis.
     */
    
public function do_this($c, $d) {
        
// source
    
}

}

Calling:

$result = foo($bar, $baz);
$mine = $object->method($a, $b);

Javascript

All files must adhere to the BasicJSFileTemplates. Javascript files should roughly follow Crockford's code conventions.