Coding and repo conventions

The short version: when in doubt make things easy for others to understand.

This repository is on a team account, so we ask that contributors fork the repo and set up branches for any issues they are working on. Please comment in the issue and let us know you're working on it (if possible) and submit pull requests when things are ready for review/merge. For more, see the Submitting and workingwith issues page.

We're not crazy strict with coding conventions, but we ask that you follow these guidelines as best you can. Please comment often and place an emphasis on legibility in your code. Making it easy for others to read is good for everyone.

##PHP conventions When in doubt, code for legibility and easy adoption. Capitalization and CamelCase should be used for class names, camelCase starting with lowercase for function names, and variable names in all lowercase snake_case as descriptive as possible.

Indentation has been kept simple — a single hard tab for each level, with curly brackets on the same line as the control statement.

So a simplified file will look something like:

<?php
/**
 * Description
 *
 * @package platform.org.cashmusic
 * @author CASH Music
 * @link http://cashmusic.org/
 *
 * Copyright (c) 2012, CASH Music
 * Licensed under the Affero General Public License version 3.
 * See http://www.gnu.org/licenses/agpl-3.0.html
 *
 */class ClassName {
    protected $variable;
    
    /**
     * Function Description
     *
     * @return value
     */public function functionName($status_code,$request_type,$action,$response_details,$contextual_message) {
        $variable_name = 'text';
        return $variable_name;
    }
} // END class
?>

Each class should have a file of it's own.

No class is final without formatted comments.

Classes and OOP practices are used for all core framework functionality and elements, but procedural code is fine where appropriate. For example the admin app is a standalone application that calls the framework. Because we don't have worries over namespace issues we can safely write the controllers as simple procedural scripts. And do.

##Javascript conventions In the admin we take advantage of jQuery. For elements and the main cashmusic.js embed script we cannot rely on an external framework and must write clean, cross-platform JavaScript without relying on external scripts. This same philosophy will extend to the new soundandvision.js script.

All JavaScript should live inside of a (function(){})(); closure. For scripts that will be embedded in external pages (like cashmusic.js and soundandvision.js) we should begin the file with an introductory semi-color to ward off any cascading bugs. And 'use strict' should appear in all closures unless there's a compelling reason for it to be omitted.

Trailing semi-colons are not optional, and all scripts should pass through JSLint with the following settings. [ Need to actually grab the settings. Whitespace, multiple var statements, etc. Coming soon. ]