These CodingGuidelines are enforced for code that is a part of the standard bitweaver distribution. If you start your own package, you are welcome to choose whatever standards you like. However, if you play in core sandbox, we need to keep things need and tidy. We have a good bit legacy code that does not follow our own conventions, however, we are fixing as fast as we can with the ArchitectureTransition.
File Types and Naming Conventions
There are several type of files, and each should be name as follow
Presentation files, such as "wiki/list_pages.php", should be named with an underscore seperateing each word. i.e. list_pages.php, and all lower case. There should be no reference to "tiki" in the file name, and it is best to keep the names short, and not redundant with the package they are in. For example "articles/edit_article.php" should be simple "articles/edit.php"
Included files if your file is only included by other files and never invoked directly, it should follow the same rules athe presentation files, however, it should have _inc.php at the end, such as "wiki/page_setup_inc.php"
Class files shoud be named identically to the name of the class they contain, i.e. "TikiSystem.php". There should be NO CODE outside of the class definition, and nothing should be declared. Sometimes, it is practical to put global function definitions in the class files, and that is acceptable. Classes should be declared in a presentation or include file.
Library files are nothing but a big pile of preocedural function definitions and have "_lib.php" at the end, such as "util/zip_lib.php". There is a bunch of legacy TikiWiki stuff like the StatsLib class in stats/stats_lib.php - one day we will get around to cleaning this stuff up.
Template files are for smarty, and they should follow convetion for presentation files, such as "wiki/templates/show_page.tpl"
There are a few special file names that the KernelPackage will look for in each Package. Below is an example for a fictional package named "somepackage":
somepackage/tiki_setup_inc.php is automatically parsed by the KernelPackage at setup time (technically by TikiSystem::scanPackages()
somepackage/templates/admin_somepackage.tpl and somepackage/admin/admin_somepackage_inc.php are automatically assumed, and will be included if you link to www.yoursite.com/kernel/admin/index.php?page=somepackage
Coding Conventions
Sometimes we need to hack something together with the intention of fixing it later. Such code should be commented with a comment starting with "@todo" and explaining what needs to be done and why it wasn't done right. Using "@todo" will make the text turn up in the source documentation if doxygen is configured to show it.
variable names are all in the camelCaps OO/Java convention. There are several underscored variables floating around, and those how we tell the unmodified TikiWiki code.
method function names functions in classes follow the OO/Java convention of camelCapFunction, note leading lowercase. There are several underscored methods floating around, and those how we tell the unmodified TikiWiki code.
hash keys should be all lower case with an underscore between words like $postlast_modified>'last_modified' - this makes life very easy and consistent between web forms and database inserts.
global function names global functions, and we only have a few, follow the stand php/C convention of underscored_function_name
To summarize naming of functions - each follows established coding conventions and each is different, however consistent.
global variables must be in the format $gVariableName like $gBitSystem
function parameters should be prefixed with $p, like: function foo( $pBar )
all define(CONSTANT) that you consider configurable by the user should have an if( defined(CONSTANT) ) check beforehand.
Please follow traditional unix brace policy. Paren styles vary, and are up to individual preference:
function foo( $pBar ) { if( condition ) { ... } }
Config Files
kernel/config_inc.php is for the users custom settings that override settings declared later on in the process. This should only be included directly by config_defaults_inc.php and during the install.
kernel/config_defaults_inc.php checks and includes config_inc.php if it exists. All defaults should be defined in this file, not in the code. config_default_inc.php should only be called from setup_inc.php. Only setting of variables and logic in setting of variables should be in this file.
kernel/setup_inc.php defines constants and sets up the environment for bitweaver. It includes the file config_defaults_inc.php which inturn includes config_inc.php. Once these files are included, logic and insanity checks are performed along with setting up of constants, etc. If a user wishes to over-ride anything by including it in config_inc.php, the code here must not complain (ie if(!defined(SOME_CONST)) { define('SOME_CONST'...etc) unless a sanity check has failed.
These CodingGuidelines are enforced for code that is a part of the standard bitweaver distribution. If you start your own package, you are welcome to choose whatever standards you like. However, if you play in core sandbox, we need to keep things neat and tidy. We have a good bit of legacy code that does not follow our own conventions, however, we are fixing as fast as we can with the ArchitectureTransition.
File Types and Naming Conventions
There are several type of files, and each should be name as follow
Directories should always be lowercase with underscores separating words - if possible, use only one word, that describes the directory best
Presentation files, such as "wiki/list_pages.php", should be named with an underscore separating each word. i.e. list_pages.php, and all lower case. There should be no reference to "tiki" in the file name, and it is best to keep the names short, and not redundant with the package they are in. For example "articles/edit_article.php" should be simple "articles/edit.php"
Included files if your file is only included by other files and never invoked directly, it should follow the same rules as the presentation files, however, it should have _inc.php at the end, such as "wiki/page_setup_inc.php"
Class files should be named identically to the name of the class they contain, i.e. "BitSystem.php". There should be NO CODE outside of the class definition, and nothing should be declared. Sometimes, it is practical to put global function definitions in the class files, and that is acceptable. Classes should be declared in a presentation or include file.
Library files are nothing but a big pile of procedural function definitions and have "_lib.php" at the end, such as "util/zip_lib.php". There is a bunch of legacy TikiWiki stuff like the StatsLib class in stats/stats_lib.php - one day we will get around to cleaning this stuff up.
Template files are for smarty, and they should follow convention for presentation files, such as "wiki/templates/show_page.tpl"
There are a few special file names that the KernelPackage will look for in each Package. Below is an example for a fictional package named "somepackage":
somepackage/bit_setup_inc.php is automatically parsed by the KernelPackage at setup time (technically by BitSystem::scanPackages()
somepackage/admin/upgrades/<version>.php is used to set package versions and control Package Upgrades.
somepackage/admin/schema_inc.php is used by kernel and install services to define tables for the package.
somepackage/admin/admin_somepackage_inc.php and the corresponding somepackage/templates/admin_somepackage.tpl are automatically assumed, and will be included if you link to www.yoursite.com/kernel/admin/index.php?page=somepackage
somepackage/templates/menu_somepackage_admin.tpl allows specification of the package admin menu.
somepackage/icons/pkg_somepackage.png icon for the package should be 48x48 pixels.
Coding Conventions
One of our most important rules in bitweaver, is to never commit code where you know it breaks something. If you have to commit something you want to have tested by others, please add appropriate comments to the code such as: // @TODO: Fix this function to work with foo. TODO is recognised by Doxygen and text editors like vim and will be highlighted in the source code.
variable names are all in the camelCaps OO/Java convention. There are several underscored variables floating around, and those how we tell the unmodified TikiWiki code.
method function names functions in classes follow the OO/Java convention of camelCapFunction, note leading lowercase. There are several underscored methods floating around, and those how we tell the unmodified TikiWiki code.
hash keys should be all lower case with an underscore between words like $post['last_modified'] - this makes life very easy and consistent between web forms and database inserts.
global function names global functions, and we only have a few, follow the stand php/C convention of underscored_function_name
To summarize naming of functions - each follows established coding conventions and each is different, however consistent.
global variables must be in the format $gVariableName like $gBitSystem
function parameters should be prefixed with $p, like: function foo( $pBar )
all define( CONSTANT ) that you consider configurable by the user should have an if( defined( CONSTANT ) ) check beforehand.
Please don't use ridiculous abbreviations. the code should be easy to follow by people other than yourself
Please follow traditional unix brace policy. Parentheses styles vary, and are up to individual preference:
For adding Javascript we have some specific Javascript Coding Guidelines, which build on these coding conventions.
Config Files
kernel/config_inc.php is for the users custom settings that override settings declared later on in the process. This should only be included directly by config_defaults_inc.php and during the install.
kernel/config_defaults_inc.php checks and includes config_inc.php if it exists. All defaults should be defined in this file, not in the code. config_default_inc.php should only be called from setup_inc.php. Only setting of variables and logic in setting of variables should be in this file.
kernel/setup_inc.php defines constants and sets up the environment for bitweaver. It includes the file config_defaults_inc.php which in turn includes config_inc.php. Once these files are included, logic and insanity checks are performed along with setting up of constants, etc. If a user wishes to over-ride anything by including it in config_inc.php, the code here must not complain (ie if(!defined(SOME_CONST)) { define('SOME_CONST'...etc) unless a sanity check has failed.