Last updated
Last updated
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.
Our direction is to adopt the wildly accepted PSR standards by the :
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 .
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.
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:
Every class must have a "class-level" docblock that contains these phpDocumentor tags at a minimum:
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"
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
, and switch
statements, include a space after the initial statement and after the closing parenthesis.
For if
statements with an else
branch, include a space after the first closing brace bracket and after the else
statement.
For if
statements with an elseif
branch, include a space after the first closing brace bracket and after the elseif
statement, and after the parenthesis.
For if
, foreach
, and switch
statements, include brace brackets, whether the code inside the statement is one line or more.
Use &&
and ||
in logic instead of AND
and OR
Layout foreach
and if
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
and default
lines, include a space before the colon.
End all case
and default
sections in switch
statements with a break;
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
or default
line in a switch
statement by one additional tab (four spaces).
Functions and Methods
Create new global functions as public static
methods in core/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()
in core/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.
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
and GROUP 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
and UPDATE
queries. Instead, use ADOdb's AutoExecute()
method.
Include SQL queries within models only, not controllers or views.
Include back-ticks around field names in queries to prevent possible naming collisions.