Coding Conventions for pH7CMS

When working with pH7CMS's code, developing extensions and modifications in the code, these coding conventions are highly recommended and will make your code easier to read/understand for other devs.

Class, Interface and Trait Names

UpperCamelCase (StudlyCaps) and alphanumeric only.

Interface Naming

When you are naming your interface, you should use "-ble" suffix as much as possible (in short, use an adjective for naming it).
Examples: Controllable, Hashable, Configurable, Serializable, Readable.

Method and Constant Names

Method Name: camelCase and alphanumeric only.
Constant Name: ALL_CAPS and alphanumeric only with the underscores to separate words.

Example:


class MyClass
{

    const MY_CONSTANT = 'abcd';

    /**
     * @param string $sVal
     * @return string Returns If the $sVal parameter is "abcd", returns "abcd", otherwise "zyxw".
     */
    public function myMethod($sVal)
    {
        if ($sVal == 'abcd')
            return 'abcd';
        else
            return 'zyxw';
    }

}

Database Table Names

all_lowercase and alphabetical only with the underscores to separate each words.
Table names have to be prefixed with "ph7_" which will be replaced by the user prefix chosen during the installation.

In pH7Framework

The classes should end with ".class.php" extension, traits should end with ".trait.php" extension and interfaces must end with ".interface.php"

Variable Names

The variables must be in camelCase and alphanumeric only.

Since PHP is not a typed language, the data found in the variables are fuzzy, so we defined a strict convention for naming variables.
The first letter of the variable must define the type of this: Here is the list of available types:

Data type prefixes:


a = Array
i = Integer
f = Float, Double
b = Boolean
c = 1 Character
s = String
by = Byte
r = Resource
o = Object
m = Mixed

Following the first letter every word used in the Variable Name must begin with a capital letter.

Example:


touch('isSunday.txt'); // Creating an empty file
$sFile = realpath('isSunday.txt');

$iDate = date('D');
$bStatus = ($iDate == 'Sun') ? true : false;
$sValue = ($bStatus) ? 'Good Sunday' : 'We are not Sunday';

$rFile = fopen($sFile, 'w');
fwrite($rFile, $sValue);
fclose($rFile);

readfile($sFile);

We use very infrequently (or in a different way) the PEAR coding standards which requires the names of the members (methods and attributes of a class) of a private class to precede it with an underscore (_).
So to distinguish between private and protected members (methods and attributes) of a class.
But you can still follow this convention if you want ;-).
By cons never put members of a class in public (if you do, it means that you do not know enough object-oriented programming to create a module or a code from us).
Also, we rarely respect the "standard" which requires a line must not exceed 80 characters because we believe this standard and obsolete nowadays screens are larger and have a code too long can become very annoying.

Function, Global Variable and Array Names

Function: lowercase and each word must be separated by underscore.

Example:


function my_function() {}

Global variables (Session, Cookie, Registry/Global variables, ...): lowercase and each word must be separated by underscore.

Example:

$GLOBALS['my_values'];

Arrays: lowercase and each word must be separated by underscore.

Arrays should be declared with the shortened syntax "[]"

Example:


$aValues = [
   'my_key' => 'Value',
   'my_key2' => 'Value 2'
];

PS: We also respect the PSR-0 and PSR-1 coding standards and we try to respect the PSR-2 coding standards but we do not always do that because some things in this new standards
are not easily followed and we do not find this especially well, but you should still try to respect this standard and the PEAR standard for your modules and pieces of code.

 


Found a Typo/Something to Add? Edit this page 🚀