FOR ARCHIVAL PURPOSES ONLY

The information in this wiki hasn't been maintained for a good while. Some of the projects described have since been deprecated.

In particular, the "Ushahidi Platform v3.x" section contains information that is often misleading. Many details about this version of Platform have changed since.

This website is an extraction of the original Ushahidi wiki into a static form. Because of that, functions like logging in, commenting or searching will not work.

For more documentation, please refer to https://docs.ushahidi.com

Skip to end of metadata
Go to start of metadata

Being a Kohana application, the Ushahidi platform naturally takes on Kohana's coding standards - which we will go ahead and replicate in this section.

NOTE: Ushahidi is based on Kohana 2.3.1 but the Kohana framework has since evolved and therefore, some of the standards outlined here may not apply to later iterations of the framework.

It is encouraged that you follow the coding style outlined in this section in order to make the code more readable, consistent and allow for easier sharing and contributing.

Class Names and File Location

There are 4 types of classes namely:

  • controllers
  • models
  • libraries
  • helpers

Controllers

Being an MVC framework, controllers stand in between models and views in the application. They pass information on to the model when data needs to be changed and they request information from the model. The rules for naming a controller are:

  • It must reside in the application/controllers directory
  • The filename must be in lowercase e.g. reports.php
  • The controller class must map to the filename with the first letter capitalized and must be appended with _Controller} e.g. Reports_Controller
  • The controller class must be subclass (directly/indirectly) of the Controller class

Additional documentation on controllers can be found here: http://docs.kohanaphp.com/general/controllers

Models

Models provide a convenient way of interacting with the database. They are a part of Kohana's ORM architecture and therefore abstract the gory details of platform-specific database calls. Kohana however doesn't force you to use models.
The rules for naming a model are:

  • Models reside in the application/models directory
  • Model filenames are lowercase and should be in the singular form of the name e.g. incident.php NOT incidents.php
  • Model class names are capitalized and must be appended with _Model e.g. Incident_Model

Additional documentation on models can be found here: http://docs.kohanaphp.com/general/models

Libraries

Rules for creating libraries are:

  • Library files reside in the application/libraries directory
  • Library class names must begin with a capitalized letter e.g. Geocoder
  • Library file names must begin with a capitalized letter and must be named the same as the library class e.g. Geocoder.php
  • A library may have _Core appended to the class name so that it can be extended (sub-classed) in the same way as Kohana's built-in libraries

Additional documentation on libraries can be found here: http://docs.kohanaphp.com/general/libraries

Helpers

Helpers are classes that are used to isolate "handy" or "useful" functionality.

Rules for creating helper classes are:

  • Helper files reside in the application/helpers directory
  • Helper file names must be in lower case and named the same as the helper class e.g. category.php
  • Helper class names must be in lower case and may be appended with _Core e.g. category_Core

Additional documentation on helpers can be found here: http://docs.kohanaphp.com/general/helpers

Coding Standards

For the source code to be consistent, we encourage all developers to follow the coding style guidelines.

Brackets

Use BSD/Allman Style bracketing. This style puts braces associated with a control statement or function definition on their own line. The exception to this rule is the opening brace for a class definition, which can be on the same line (as the class name).

Naming Conventions

Kohana uses under_score naming, not camelCase naming.

Classes
Functions and Methods

Function names should be in lowercase and use under_scores to separate words:

Variables

Variable names should lowercase and use under_score, not camelCase:

Indentation

Use tabs to indent your code. The use of spaces is forbidden.

Vertical spacing (for multi-line) is done with spaces. Tabs are not good for vertical alignment because different people have different tab widths.

Single-line Statements

Single-line IF should only be used when breaking normal execution (e.g. return or continue)

Comparison Operations

Use AND and OR for comparison.

elseif, NOT else if

Parentheses
  • There should be one space after the statement name
  • The "!" (bang) character must have a space on either side to ensure maximum readability. Except in the case of a bang in type casting, there should be no whitespace after an opening parentheses or before a closing parentheses.
Ternaries

Ternary operations should follow a standard format. Use parentheses around expressions only, not around variables.

When separating ternaries into lines, spaces should be used to line up the operators, which should at the front of successive lines:

Basic Documentation Commenting

We use phpDocumentor, a tool for creating documentation directly from both PHP and external documentation, to keep track of all our code documentation. The documentation within the code is done using PHPDoc which is an adaptation of Javadoc for the PHP programming language.

The objective of documenting code is to makes it easier to understand and lower the barrier to entry for developers wishing to contribute to the codebase. It also facilitates painless maintenance (refactoring, bug fixes etc).

The first thing to take note of is that PHPDoc comments must be enclosed in DocBlocks. A DocBlock is a C-stlye comment that begins with a /** and with a leading asterisk * on each line. Any line within a DocBlock that doesn't begin with a * will be ignored. Example:

Secondly, DocBlocks must precede the code you are adding comments to. For example, if you wanted to document the function foo(), you would proceed as follows:

  • No labels