LiveWhale CMS

Welcome, Guest Login

Support Center

Styleguide: PHP

Last Updated: Sep 03, 2015 09:11AM PDT

Basic Coding Style

  • Always use a complete set of full-form PHP tags, e.g. open with <?php and close with ?>. We get the point of not having a final closing tag on php-only documents, but as Schupp says: “Trailing whitespace is for suckers.”
  • When writing a PHP-only document, don’t leave whitespace after the final closing tag.
  • Try to keep lines around 80-120 characters.
  • Leave no trailing whitespace unless part of a comment.
  • Never put more than one statement per line
  • Use typed equivalence checking ===/!== except when specifically allowing for string comparisons, e.g. with a $_GET variable.
  • Only use the ternary operator ?: when if/else constructs are trivial and fit on a single line. (That means you shouldn’t nest them.)
  • Use uppercase for TRUEFALSE and NULL.
  • Always quote associative array keys, e.g. array['key'].
  • If in doubt, you could do worse than follow the Zend examples.

Indentation and Spacing

  • Use a single tab per level of indent.
  • Use spaces around operators (including concatenation .), after commas, colons and semicolons, except for = when used in an argument default.
  • Don’t use spaces after ([ or before ]).
  • Use a space before argument paranthesis when defining a function or method, but not when calling it.
  • Always use braces {} even when optional. Prepend the opening brace with a space and indent the closing brace to the same level as the opening brace line.
  • Always indent ifs, fors,foreaches, whiles, switches and the like.
  • Newline and indent case statement actions.
  • Always leave a newline between a function or method and preceeding code. (The newline appears above any associated documentation.)

Naming

  • Use snake_case for variables.
  • Use camelCase for functions and methods.
  • Use CappedCamelCase for class names.
  • Use SCREAMING_SNAKE_CASE for constants.

Regular Expressions

  • Since / is so often a character in HTML, prefer ~ (tilde) as the delimiter for regexp pattern strings.
  • Break complex/long regular expressions into multiple pattern strings over multiple lines so that you can document the pattern.
  • With complex matching, write test content with expected positives and negatives and use preg_match_all to evaluate it during testing, e.g. expect X matches.
// Complex
$pattern = '~(' . '<[a-zA-Z]+[^>]* (id="([^"]+)")[^>]* (class="[^"]*optional[^"]*")[^>]*>' // element with id and class=optional
. '|' // or
. '<[a-zA-Z]+[^>]* (class="[^"]*optional[^"]*")[^>]* (id="([^"]+)")[^>]*>' // element with class=optional and id
. ')' . '\s*' // that is empty
. '</[a-zA-Z]+>' // and closed properly
. '~mU'; // where emptiness includes newlines and is ungreedy

Testing

LiveWhale has extensive functional/unit testing for all core code and modules. We recommend that if you are sharing your modules with the LiveWhale developer community that you include a /tests folder in your repository.

PHP Documentation

​We are working on what the formal documentation style will be, although like that with JavaScript, the majority of the documentation will occur in blocks that immediately preceed the function/method they reference.

  • Block comments should be renderable into HTML via Markdown.
  • End-of-line comments are also allowed, but should only be used when code itself is not explicit.
  • Again if in doubt, you could do worse than follow the Zend examples.
eb8f96c071020d8b0923da726d6cab65@livewhale.desk-mail.com
https://cdn.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete?b_id=4256