Actions

Difference between revisions of "Developer Area/Coding guidelines"

From Mahara Wiki

< Developer Area
(→‎if/while/for statements: updated in Developer Area/Coding guidelines/PHP files)
(3 intermediate revisions by the same user not shown)
Line 35: Line 35:
 
'''Recommended:'''
 
'''Recommended:'''
 
* There is no requirement that the scripts are wrapped at 80 columns, however developers are asked to wrap long lines sensibly.
 
* 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 [http://en.wikipedia.org/wiki/PHPDoc PHPDoc] and [http://usejsdoc.org/ JSDoc].
 
* 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.
 
** This makes them more visible to people scanning the page, and ensures they won't be hidden off the side of the page if the reader's editor window is small.
 
 
Example:
 
 
<source lang="php" container="div">
 
/**
 
* 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);
 
    }
 
}
 
</source>
 
== PHPDocumentor ==
 
Building local docs is simple enough. We recommend using the official Docker build at [https://hub.docker.com/r/phpdoc/phpdoc/tags?page=1&ordering=last_updated phpdoc/phpdoc].
 
 
Your experience with the actual documentation may vary. There has been a recent push this year (2021) to get the local documentation more fully complete.
 
 
Execute from the repo root to build the full documentation.
 
<source>
 
mkdir -p docs/complete;
 
docker run --rm -v ${PWD}:/data phpdoc/phpdoc  -d ./htdocs/ -t ./docs/complete
 
</source>
 
 
To build a subset:
 
<source>
 
mkdir -p docs/test;
 
docker run --rm -v ${PWD}:/data phpdoc/phpdoc  -f ./htdocs/path/to/directory/* -t ./docs/test
 
</source>
 
  
 
=Language Constructs=
 
=Language Constructs=
  
 
==Strings==
 
 
'''Recommended:'''
 
* Strings should be quoted with single quotes (')
 
** Unless you are interpolating a variable
 
** Or writing a string with lots of single quotes in it.
 
* Variable interpolations should be written with {curly braces} around them.
 
 
Examples:
 
 
<source lang="php" container="div">
 
$a = 'This is a string.';
 
$b = "This's a string that's got lots of apostrophes (i.e. <b>'</b> characters), in it. Ain't it pretty nifty?";
 
$c = "My {$field} is {$users[$1]->$field}";
 
</source>
 
 
==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.
 
 
<source lang="php" container="div">
 
require_once('my/file.php');
 
</source>
 
 
'''NOT''':
 
 
<source lang="php" container="div">
 
require_once 'my/file.php';
 
require_once ('my/file.php');
 
</source>
 
 
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 or parentheses 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''':
 
 
<div class="plugin tightenable"><code><font color="#000000"> <font color="#007700">if (</font><font color="#0000bb">1 </font><font color="#007700">== </font><font color="#0000bb">2</font><font color="#007700">) {<br />     die(</font><font color="#dd0000">'omg'</font><font color="#007700">);<br /> }<br /><br /> while (</font><font color="#0000bb">$i </font><font color="#007700">&lt; </font><font color="#0000bb">3</font><font color="#007700">) {<br />     echo </font><font color="#dd0000">'I am ' </font><font color="#007700">. </font><font color="#0000bb">$i</font><font color="#007700">;<br /> }<br /><br /> for (</font><font color="#0000bb">$i </font><font color="#007700">= </font><font color="#0000bb">0</font><font color="#007700">, </font><font color="#0000bb">$j </font><font color="#007700">= </font><font color="#0000bb">7</font><font color="#007700">; </font><font color="#0000bb">$i </font><font color="#007700">&lt; </font><font color="#0000bb">34</font><font color="#007700">, </font><font color="#0000bb">$j </font><font color="#007700">!= </font><font color="#0000bb">3</font><font color="#007700">; </font><font color="#0000bb">$i</font><font color="#007700">++, </font><font color="#0000bb">$j</font><font color="#007700">--) {<br />     echo (</font><font color="#0000bb">$i </font><font color="#007700">* </font><font color="#0000bb">$j</font><font color="#007700">) . </font><font color="#dd0000">' is a silly number'</font><font color="#007700">;<br /> }<br /><br /></font><font color="#ff8000">// Note bracing style of else if/else clauses<br /> // Also note: do not use elseif<br /></font><font color="#007700">if (</font><font color="#0000bb">$a </font><font color="#007700">== </font><font color="#0000bb">$b</font><font color="#007700">) {<br />     echo </font><font color="#dd0000">"a = b"</font><font color="#007700">;<br /> }<br /> else if (</font><font color="#0000bb">$c </font><font color="#007700">== </font><font color="#0000bb">$d</font><font color="#007700">) {<br />     echo </font><font color="#dd0000">"c = d"</font><font color="#007700">;<br /> }<br /> else {<br />     echo </font><font color="#dd0000">"e = ?"</font><font color="#007700">;<br /> }<br /><br /></font><font color="#ff8000">// Ternary operator<br /></font><font color="#0000bb">$a </font><font color="#007700">= (</font><font color="#0000bb">$b </font><font color="#007700">== </font><font color="#0000bb">true</font><font color="#007700">) ? </font><font color="#dd0000">'hello' </font><font color="#007700">: </font><font color="#dd0000">'goodbye'</font><font color="#007700">;<br /></font><font color="#ff8000">// When used with other things on each side in the same statement:<br /></font><font color="#0000bb">$a </font><font color="#007700">= </font><font color="#dd0000">'foo' </font><font color="#007700">. ((</font><font color="#0000bb">$b </font><font color="#007700">== </font><font color="#0000bb">true</font><font color="#007700">) ? </font><font color="#dd0000">'hello' </font><font color="#007700">: </font><font color="#dd0000">'goodbye'</font><font color="#007700">) . </font><font color="#dd0000">'bar'</font><font color="#007700">;<br /><br /></font><font color="#ff8000">// A complicated condition. Note location of condition,<br /> // and location of ending bracket and brace.<br /> // todo: what was the decision here regarding conditions on the "if (" line?<br /></font><font color="#007700">if (<br />     </font><font color="#0000bb">$sacrificedgoats </font><font color="#007700">== </font><font color="#0000bb">$availablegoats<br />     </font><font color="#007700">&amp;&amp; (</font><font color="#0000bb">$dogs </font><font color="#007700">== </font><font color="#0000bb">$cats<br />     </font><font color="#007700">|| </font><font color="#0000bb">1 </font><font color="#007700">!= </font><font color="#0000bb">2</font><font color="#007700">)<br />     || (</font><font color="#0000bb">$yesterday </font><font color="#007700">&gt;&gt; </font><font color="#0000bb">$tomorrow </font><font color="#007700">== </font><font color="#0000bb">4</font><font color="#007700">)<br /> ) {<br />     </font><font color="#ff8000">// Do stuff<br /></font><font color="#007700">}<br /></font> </font> </code></div>
 
 
Examples of what is '''bad''':
 
 
<div class="plugin tightenable"><code><font color="#000000"> <font color="#007700">if ( </font><font color="#0000bb">$a </font><font color="#007700">== </font><font color="#0000bb">$b </font><font color="#007700">)<br /> {<br />     echo </font><font color="#dd0000">'hi'</font><font color="#007700">;<br /> }<br /><br /> if(</font><font color="#0000bb">$c </font><font color="#007700">== </font><font color="#0000bb">$d</font><font color="#007700">) {<br />     echo </font><font color="#dd0000">'hi'</font><font color="#007700">;<br /> } else {<br />     echo </font><font color="#dd0000">'bye'</font><font color="#007700">;<br /> }<br /><br /> if (</font><font color="#0000bb">$e</font><font color="#007700">==</font><font color="#0000bb">$f</font><font color="#007700">)<br /> {<br />     echo </font><font color="#dd0000">'hi'</font><font color="#007700">;<br /> }<br /> else<br /> {<br />     echo </font><font color="#dd0000">'bye'</font><font color="#007700">;<br /> }<br /></font> </font> </code></div>
 
 
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> </code></div><div id="section_7">
 
  
 
==switch/case statements==
 
==switch/case statements==

Revision as of 15:12, 8 October 2021

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.

Separate pages with more information:


Accessibility

Mahara should be accessible to anybody. We are aiming to follow the WCAG 2.1 AA principles. There are a areas that we identified that require changes to achieve that aim. New and changed code should always be written with accessibility principles and guidelines in mind rather than tagged on 'when there is time'. Writing code accessible from the start makes it better code and requires less refactoring later on.

The style guide, accessible via 'yourmaharadomain/theme/styleguide.php', gives useful basic information for a lot of style elements.

Since the field of accessibility is changing, certain elements may require updates over time. You can find more information on our 'Accessibility' page.

File Headers

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.

Closing php tags ?> should be omitted.

Whitespace

Required:

  • Indentation is using four (4) spaces, not tabs.
  • Line endings should be "Unix-style" (\n), not "Windows-style" (\r\n).
  • Avoid extra whitespace at the end of modified lines.
  • Avoid editing whitespaces unrelated to your specific code change, when submitting a patch. It makes reviewing the patch more difficult and add unnecessary noise to the change history.


Recommended:

  • There is no requirement that the scripts are wrapped at 80 columns, however developers are asked to wrap long lines sensibly.

Language Constructs

switch/case statements

"case" should use multiline formatting:

switch ($var) {
    case 1:
        a = 25;
        b = 100;
        break;
    default:
        a = 0;
        b = 0;
}

NOT

case 1: a = 25; b = 100; break;

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.

Aligning = signs for variable assignment is up to the developer, although they should use common sense in such decisions.

Hardcoded binary data is not allowed for security reasons.

Hardcoded serialised data is not allowed for security reasons.

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
$count_i = 6;
// Uppercase letters
$myFish = $yourFish;

$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 parentheses as required.

Classes, Functions and Methods

Nameing

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

class ExampleWhizbang {
    // ...
}

Leave double empty line between classes blocks in the code.

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

function do_something(){
    // ...
}

NOT

function doSomething() {
    // ...
}

Function name must start with a letter (no _ character before function name, unless you declare magic method where double underscore is used).

Leave single empty line between two function blocks and between function block and code if function is used in non-library file.

The built-in PHP class "stdClass" should be written with a lowercase s, uppercase C, because that is its actual name. Other capitalizations, such as "StdClass" will not cause an error because invocations of classnames and functions are case-insensitive in PHP. However, it is good style to use the same capitalization as the declaration of the class/function.

Constructors without arguments should be called with empty parentheses after them.

Good:

$a = new stdClass();
$b = new RssBlock();

Bad:

// stdClass written incorrectly
$a = new StdClass();

// no parentheses after constructor
$b = new RssBlock;

// lowercase user-created class
$c = new fancyblock();

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.