File Formatting

• Try to begin your code blocks with < ? php not < ? . Concrete is moving toward this as a strict requirement.
• Indent your code with tabs, not spaces.
• If a file contains only PHP code, including the closing ?> tag is strongly discouraged.
• A line length of around 80 characters is strongly encouraged.
• UNIX style line endings are required.

Naming Conventions

Filenames

• ALL filenames should be lowercase, with an underscore ("_") used to separate semantic terms. No uppercase permitted.

Class/Function Names

• Block class names are required to be in the format MyBlocksNameBlockController, where "MyBlocksName" is the camel-cased version of the block's directory in the filesystem. So if your block is named image_gallery in the filesystem, it must be named ImageGalleryBlockController in the controller.php file. Note: If your block is named imagegallery in the filesystem, capitalization is still important - it must be ImagegalleryBlockController in the controller.php file.
• Helpers are required to be in the format HelperNameHelper. So if you're adding a new helper to the helpers directory, and its name is "ldap_authenticate" then your helper class name must be LdapAuthenticateHelper.

Class/Function Methods

• Core models and libraries should usually simply be named as they are in the database ("page.php","Page" and "Pages", "page_theme.php", "PageTheme" and "PageThemes"), etc..
• Within models, all functions and class names should be camel-cased, with no underscores used to separate terms.
• Within controllers, all functions should be lowercase, with underscores used.

Parameters

• All controller parameters should be lowercase, with underscores used.

Database Tables

• All database tables should be camel-cased, not lowercase, with the following exception:
  • Tables specifically for blocks should start with "bt" in lowercase, and proceed from there on.
  • If a block uses multiple tables to store data, all tables should begin with block, and ought to include that block's base table name in their names. For example, if I have a poll block, which stores its core block data in btPoll, but I also have questions and results tables, my database tables ought to be:

btPoll
btPollQuestions
btPollAnswers`

Coding Style

Strings

• String Literals: When a string is literal (contains no variable substitutions), the apostrophe or "single quote" should be used to demarcate the string.
• String Literals w/apostrophes: When a literal string itself contains apostrophes, it is permitted to demarcate the string with quotation marks or "double quotes".
• Variable Substitution: Variable substitution is permitted using either of these two forms:

$greeting = "Hello $name, welcome back!";
$greeting = "Hello {$name}, welcome back!";

For consistency no other forms should be used. * String Concatenation: Strings may be concatenated using the "." operator. A space must always be added before and after the "." operator to improve readability:

$dish = 'Fruit' . ' ' . 'Salad';

• When concatenating strings with the "." operator, it is permitted to break the statement into multiple lines to improve readability. In these cases, each successive line should be padded with whitespace such that the "."; operator is aligned under the "=" operator:

$sql = "SELECT `uID`, `uName` FROM `Users` "
     . "WHERE `uName ` = 'andrew' "
     . "ORDER BY `uName` ASC ";

Arrays

• Numerically Indexed Arrays
  • Negative numbers are not permitted as indices.
  • It is strongly recommended that all arrays have a base index of 0.
  • When declaring indexed arrays with the array construct, a trailing space must be added after each comma delimiter to improve readability:

$sampleArray = array(1, 2, 3, 'Concrete');

• Associative Arrays
  • When declaring associative arrays with the array construct, it is encouraged to break the statement into multiple lines. In this case, each successive line must be padded with whitespace such that both the keys and the values are aligned.

Classes and Methods/Functions

• Class names ought to start at the leftmost edge of your code, with no indentation.
• All braces after classes and function should start on the same line as the function/class directive.
• When finishing out a class/function, braces ought to be on their own line, and always one per line. The final brace of a function or class should be at the same indent level as the beginning of that function/class.
• PHP5 keywords should be used when declaring class variables.

Control Statements

If/Else If/Else

• Control statements based on the if and elseif constructs must have a single space before the opening parenthesis of the conditional, and a single space after the closing parenthesis.
• Within the conditional statements between the parentheses, operators must be separated by spaces for readability. Inner parentheses are encouraged to improve logical grouping of larger conditionals.
• The opening brace is written on the same line as the conditional statement. The closing brace is always written on its own line. Any content within the braces must be indented with one tab.
• Use of the "elseif" construct is permitted but highly discouraged in favor of the "else if" combination.
• Omitting braces for single-line if's or else's is never allowed.

Switch Statements

• Control statements written with the "switch" construct must have a single space before the opening parenthesis of the conditional statement, and also a single space after the closing parenthesis.
• All content within the "switch" statement must be indented with one tab. Content under each "case" statement must be indented an additional tab.

switch ($numPeople) {
    case 1:
        break;

    case 2:
        break;

    default:
        break;
}

• The construct default may never be omitted from a switch statement.

Alternate syntaxes

• PHP's alternative syntax for control structures is not allowed.