Coding Standards
Coding Standards
Due to the fact that the Elentra code base has been continually evolving, some of the existing source code does not necessarily adhere to the Elentra Platform Coding Standards defined below. If you encounter something that does not follow the coding standards, it is our hope that you (as a developer and contributor) will update and test the files accordingly.
Important Note If you do not like something about our coding standards, please don't be passively adoptive. We are certainly willing to listen and potentially adjust providing that:
You are willing and able to clearly explain and defend your well thought out position.
You are willing to do something to help implementing your ideas.
You can convince the majority of community to agree with your position.
Thank you for helping to make the Elentra Platform development experience a good one.
PHP Standards
Our direction is to adopt the wildly accepted PSR standards by the PHP Framework Interop Group:
Source Code Documentation
All source code documentation blocks ("docblocks") must be compatible with the phpDocumentor format. Describing the phpDocumentor format is beyond the scope of this document, but for more information visit http://phpdoc.org.
All source code files written for Elentra or that operate within the platform must contain a "file-level" docblock at the top of each file, as well as a "class-level" docblock immediately above each class.
Below are examples of such docblocks.
Please Note The sharp, #
, character should never be used to start source code comments, instead use: //
or /* */
format.
Files
Every file that contains Elentra PHP code must have a "file-level" docblock at the top of the file that contains these phpDocumentor tags at a minimum:
Classes
Every class must have a "class-level" docblock that contains these phpDocumentor tags at a minimum:
Functions
Every function, including object methods, must have a docblock that contains at a minimum:
A description of the function
All of the arguments
All of the possible return values
If a function/method may throw an exception, use "@throws"
Code Formatting and General Rules
General Formatting
All indenting is set to 4 spaces (no tabs).
Keep indenting at the level of the HTML indent when mixing PHP and HTML, and vice versa.
Do not increase or decrease indent for
<?php
or?>
tags.Do not use PHP short tags (
<?
or<?=
), instead use the full opening tag (<?php
and<?php echo
).
Variables and Constants
Constants should always be declared in upper case
Variables which are used between more than one file (what we call minor global variables) are also in all upper case
Variables which are used within only one file should be in all lower case
Variables and Constants with multi-word names should have each word separated with an underscore
Always validate
$_GET
and$_POST
variables and place them in a$PROCESSED
array for creating or editing records in databases or in regular variables for program logic
If, Foreach and Switch statements
For
if
,foreach
, andswitch
statements, include a space after the initial statement and after the closing parenthesis.For
if
statements with anelse
branch, include a space after the first closing brace bracket and after theelse
statement.For
if
statements with anelseif
branch, include a space after the first closing brace bracket and after theelseif
statement, and after the parenthesis.For
if
,foreach
, andswitch
statements, include brace brackets, whether the code inside the statement is one line or more.Use
&&
and||
in logic instead ofAND
andOR
Layout
foreach
andif
statements on at least 3 lines:The statement, parameters, and open brace-bracket
A new line with code to be executed
One more line with a closing brace bracket.
Layout
switch
statements with at least 5 lines:same as above plus:
at least one
case "parameter" :
line before the code to be executed.a
break;
line after the code to be executed.
For
case
anddefault
lines, include a space before the colon.End all
case
anddefault
sections inswitch
statements with abreak;
line which is indented one tab less than the code to be executed.Indent all code within brace brackets by one additional tab (four spaces).
Indent all code after a
case
ordefault
line in aswitch
statement by one additional tab (four spaces).
Functions and Methods
Create new global functions as
public static
methods incore/library/Entrada/Utilities.php
.Historical global functions are declared in
core/includes/functions.inc.php
.
Separate multi-word function names with underscores.
Define functions primarily used only in one module as methods of that module's class (e.g.,
Entrada_Events::filter_events()
incore/library/Entrada/Events.php
).Group like functions / methods together in the same file where possible.
Include a space after the closing parenthesis and before the opening brace bracket in function declarations.
SQL Standards
If the query you are writing is over 120 characters long you should add line breaks and align the query so
JOIN
,WHERE
,ON
,AND
,ORDER BY
andGROUP BY
keywords start a new line and are indented to line up with the first statement of the query.All of the query except the field, table and database names should be in uppercase.
To prevent SQL injection vulnerabilities, use prepared statements whenever possible, otherwise use ADOdb's qstr() method
".$db->qstr($variable)."
to add variables into queries.Avoid writing your own
INSERT
andUPDATE
queries. Instead, use ADOdb'sAutoExecute()
method.Include SQL queries within models only, not controllers or views.
Include back-ticks around field names in queries to prevent possible naming collisions.
Using prepared statements
Using ADOdb qstr()
Last updated