Coding conventions

NOTE: These coding conventions apply for FluxBB 2.0 only. You can find coding conventions for FluxBB 1.5 and previous versions on this page.

The rules and recommendations set forth in this section apply to PHP, Javascript, SQL and any other programming language (where applicable) in use by FluxBB. Please note that tabs in this document have been substituted by spaces for visual reasons only.

Naming convention

FIXME The naming rules apply to the naming of variables, functions, classes, attributes, arrays, array elements, HTML form fields, query string parameters, database tables, database fields as well as any other applicable entities.

Variable names

  • All names should use lowerCamelCase.
  • Do not use _ (underscore) as word separator.
  • Use the prefix num for entities that represent a count. E.g. numUsers. Use the prefix cur for entities that represent the current element when iterating through any type of collection (database result set, array etc). E.g. curUser.
  • Avoid all forms of Hungarian notation or derivatives or variations thereof.
  • Use common sense. If in doubt, look at similar sections in the FluxBB source code.

Class names

  • All class names should be upper-case.
  • Words should be separated by underscores, as in Flux_Database_Query (only if namespaces are not used).

Method names

  • All class method and function names should use lowerCamelCase.

Brace policy and indentation

The indent style and brace policy of choice for the FluxBB project is the Allman style. All indentation should be made using tabs (with a tab size of 4), not spaces.

Here's an example:

if ($a == $b)

Note the whitespace between the keyword and the parenthesis. “Braceless” one-line blocks are NOT allowed.

Line breaks and encoding

All line breaks should be Unix-style / LF (\n) only. Set your editor to save files with UNIX style line breaks. All files should be saved using UTF-8 encoding.


The following rules apply only to PHP.

  • Use singlequotes as opposed to doublequotes when working with strings. E.g. $str = 'Users: '.$numUsers; as opposed to $str = “Users: $numUsers”;.
  • Don't use PHP's short tags (<?, <?=), but use its full equivalent (<?php, <?php echo).


The following rules apply only to SQL.

  • Always pass potentially harmful (user-submitted) data to the database layer using prepared statements.