Reading/Web/Coding conventions

This document briefly describes guidelines for writing code for the MobileFrontend MediaWiki extension.

Commit Messages
When committing make sure you clearly label the type of commit. This helps us build nice reader friendly deployment logs like this one.
 * Story: Commit should begin with 'Story X:' prefix where X is the card number in Mingle
 * Bug: Bugs should finish with "Bug: X" where X is the bug number in Bugzilla. There should be no whitespace underneath.
 * Hygiene: When tidying up code e.g. refactoring, addressing FIXME's and there is no related bug number, prefix your commit with hygiene.
 * QA: Prefix with "QA:" for any patch which updates or builds on our acceptance/browser tests.
 * i18n: Any patch which fixes a localisation problem or updates localisation messages and that does not have a bug number should commence with 'i18n:'
 * Dependencies: When committing a patch with a dependency or dependencies, be sure to include "Dependency: ChangeId" where ChangeID is the change id of the commit that needs to be merged beforehand. When multiple dependencies exist be sure to list them on separate lines.

File names
File names should use camelCase. In case of PHP files, the name should start with a capital letter and should be named after the main class they contain. If a JavaScript file defines a constructor, then its name should also start with a capital letter. Other files should be started with a lowercase letter.

Do not use the  prefix.

PHP test files should be suffixed with, JavaScript test files should be prefixed with.

Template and LESS/CSS files used only by a single class in JavaScript should be named after the class, e.g..

Config variables
Global config variables set by MobileFrontend need to identify the extension in some way, by general MW convention.

Config variables should be camel cased and prefixed with $wgMF Examples:
 * $wgMFPhotoUploadEndpoint
 * $wgMobileFrontendLogo

Previously '$wgMobileFrontend' was used but was abandoned in favor of '$wgMF...' because of brevity.

ResourceLoaderModules
This is a WIP and the spec is not finalised but the current suggested naming convention is as follows:

When naming a ResourceLoader module in Resources.php, the module name should reflect the functionality it offers and where. For example, the name  describes a module containing styles that are only applied to the Special:MobileDiff page,   describes scripts that should only be applied to the Special:MobileDiff.

Try to group modules by their type:
 * modules related to special pages should start with
 * modules related to the Minerva skin used by MobileFrontend should start with
 * modules implementing a particular feature should start with a word describing it, e.g.

There is usually no need include 'beta' or 'alpha' in the module name. Please try to use comments instead to describe where those features reside.

Naming functions

 * When returning true or false the function should be prefixed with 'is' or 'has' e.g. isBetaGroupMember, isLoggedIn etc.Functions should be camel cased.

ResourceLoader modules
When naming classes try to avoid the MF prefix and instead try and describe what it does differently from a normal ResourceLoader module

Examples:
 * MobileSiteModule
 * MobileDeviceDetectModule.php

All classes should be written on the basis that one day they might make it into the desktop site. Note: MFResourceLoaderModule needs renaming - it pre-parses messages and provides template rendering.

File organisation
All classes no matter how small should be in a separate file. This helps with making classes easier to find within the codebase. All files should live in the includes folder (with the exception of global PHP files such as MobileFrontend.php). Remember not every one uses the same IDE as you!

Filenames should be mapped to class names. Burying multiple classes in a file, even if they're small classes, makes discovery a little more difficult for users with basic IDEs. We should encourage discovery of our code to newbies who are not familiar with the codebase.


 * api: Anything related to api goes here
 * modules: Put ResourceLoader module classes here
 * skins: Put skins here
 * specials: put SpecialPage modules here

i18n messages
If your message contains a single quote/apostrophe, wrap the entire message in double quotes rather than escaping the single quote.

URL Routing (Use of the URL hash)
When navigating to a route always prefix it with '/' to distinguish it from element IDS

e.g. #/notifications not #notifications

File organisation
Always use camel case. Group related files in folders describing the functionality.

Naming conventions
Standard MediaWiki naming conventions apply. Any JavaScript must pass the Manual:Coding_conventions/JavaScript.

Use camelCase for variable names.

When naming events use lowercase letters and a hyphen as the word separator ( is good,   is bad).

Start constructor functions with capital letters.

Use  as the name of the variable holding event data in event handlers.

Modules
Each JavaScript file can be a module, i.e. can expose some functionality to other JavaScript files.

A module has one of two purposes
 * 1) Provide reusable functionality via a class and the use of M.define: A module should only create one class and should use an uppercase character when naming the class e.g. Toast, Api, EditorOverlay. The module may also define an instance of itself via M.define - e.g. M.define( 'api' ) = new Api
 * 2) Execute some code providing some new functionality: This tends to use classes defined in other modules.

When writing modules be sure to wrap each module (in fact, every JavaScript file) in a closure.

Use closure's arguments to alias  and   objects as  and   respectively (but only if the module needs them):

Expose module's functionality using :

Module's name should be the same as module's file name (without the extension).

If the only thing exposed by a module is a class/constructor function, then the module name (and file name) should be capitalized:

Use other module's functionality using :

jQuery
Use  rather than   when creating new DOM nodes (or even better, use templates).

Use  to bind events rather than other convenience functions such as click

Use  as a return value of asynchronous functions. Use / for success and  /  for errors.

Use jQuery objects in favor of native DOM elements (for the sake of consistency).

Avoid using  unless necessary. Most of the JavaScript files are loaded at the bottom of the page anyway.

Avoid jQuery/HTML spaghetti code, instead use  and Hogan templates (same syntax as Mustache).

CSS/LESS
We currently use LESS to generate stylesheets. You need Node.js for the LESS compiler to run.

Ensure all CSS passes the Manual:Coding_conventions/CSS.

Do not use the  prefix.

Use lowercase letters and a hyphen as the word separator in class and id names ( is good,   is bad).

Avoid using attribute selectors - these are known to cause issues in the phonegap app which shares some of this codebase.

Units
When using values less than 1 write without the leading 0 e.g. .5em not 0.5em, .37em not 0.37em

Use shorthand where possible
Where ever possible use the shorthand rule to reduce number of css rules. As a rule of thumb if you have a margin-left and a margin-top in the same rule you should probably be using margin. Use background rather than background-image where possible.

HTML
HTML should validate via W3C validator. Note, at the current time do not worry about markup introduced via wikitext and the 1 validation error that occurs due to MediaWiki core.