|
Hello
Roy you might want to take a look at how Moodle handles contributions.
It explains the coding style, database style etc.
Development Coding Guidlines
Interface Guidlines
Short snippet from there page on how they have laid it out
*General rules
All code files should use the .php extension.
All template files should use the .html extension.
All text files should use Unix-style text format (most text editors have this as an option).
All php tags must be ‘full’ tags like <?php ?> ... not ‘short’ tags like <? ?>.
All existing copyright notices must be retained. You can add your own if necessary.
Each file should include (require_once) the main config.php file.
...
*Coding style
1. Indenting should be consistently 4 spaces. Don’t use tabs AT ALL.
2. Variable names should always be easy-to-read, meaningful lowercase English words. If you really need more than one word then run them together, but keep them short as possible. Use plural names for arrays of objects.
GOOD: $quiz
GOOD: $errorstring
GOOD: $assignments (for an array of objects)
GOOD: $i (but only in little loops)
BAD: $Quiz
BAD: $aReallyLongVariableNameWithoutAGoodReason
BAD: $error_string
3. Constants should always be in upper case, and always start with the name of the module. They should have words separated by underscores.
define("FORUM_MODE_FLATOLDEST", 1);
4. Function names should be simple English lowercase words, and start with the name of the module to avoid conflicts between modules. Words should be separated by underscores. Parameters should always have sensible defaults if possible. Note there is no space between the function name and the following (brackets).
function forum_set_display_mode($mode=0) {
global $USER, $CFG;
if ($mode) {
$USER->mode = $mode;
} else if (empty($USER->mode)) {
$USER->mode = $CFG->forum_displaymode;
}
}
5. Blocks must always be enclosed in curly braces (even if there is only one line). Moodle uses this style:
if ($quiz->attempts) {
if ($numattempts > $quiz->attempts) {
error($strtoomanyattempts, "view.php?id=$cm->id");
}
}
6. Strings should be defined using single quotes where possible, so that less memory is used.
$var = 'some text without any variables';
$var = 'with special characters like a new line '."\n";
$var = 'a very, very long string with a '.$single.' variable in it';
$var = 'some '.$text.' with '.$many.' variables '.$within.' it';
7. Comments should be added as much as is practical, to explain the code flow and the purpose of functions and variables.
**Every function (and class) should use the popular phpDoc format. This allows code documentation to be generated automatically.
**Inline comments should use the // style, laid out neatly so that it fits among the code and lines up with it.
/**
* The description should be first, with asterisks laid out exactly
* like this example. If you want to refer to a another function,
* do it like this: {@link clean_param()}. Then, add descriptions
* for each parameter as follows.
*
* @param int $postid The PHP type is followed by the variable name
* @param array $scale The PHP type is followed by the variable name
* @param array $ratings The PHP type is followed by the variable name
* @return mixed
*/
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {
if (!$ratings) {
$ratings = array(); // Initialize the empty array
if ($rates = get_records("forum_ratings", "post", $postid)) {
// Process each rating in turn
foreach ($rates as $rate) {
....etc
Database structures
1.Every table must have an auto-incrementing id field (INT10) as primary index. (see IdColumnReasons)
2.The main table containing instances of each module must have the same name as the module (eg widget) and contain the following minimum fields:
*id - as described above
*course - the id of the course that each instance belongs to
*name - the full name of each instance of the module
3.Other tables associated with a module that contain information about ‘things’ should be named widget_things (note the plural).
4.Table and column names should avoid using reserved words in any database. Please check them before creation.
5.Column names should be always lowercase, simple and short, following the same rules as for variable names.
6.Where possible, columns that contain a reference to the id field of another table (eg widget) should be called widgetid. (Note that this convention is newish and not followed in some older tables)
7.Boolean fields should be implemented as small integer fields (eg INT4) containing 0 or 1, to allow for later expansion of values if necessary.
Most tables should have a timemodified field (INT10) which is updated with a current timestamp obtained with the PHP time() function.
8.Always define a default value for each field (and make it sensible)
|
I’m not sure why anyone uses spaces for indentations instead of tabs. Tabs are a million times faster when writing code. Also, can some of the programmers here explain this style of code to me?
Whatever style Varien likes to use for Magento, that’s what I will use for any contributions I release. Consistency is a big part of quality.
