- We use only the
TABcharacter for indentation.
- We use
UpperCamelCasefor class names, and
lowerCamelCasefor method and property names.
- Methods and properties that begin with an underscore (
- Variables which contain jQuery elements should be named like
$element, starting with a
$. If it is a private jQuery element, prefix it with
- We use
thatas a name for a closure reference to
this, but try to avoid it if there’s the possibility of scope binding. Unfortunately jQuery’s event handlers do not allow easy scope binding.
TODO: still determine this.
RequireJS module skeleton¶
WARNING: still has to be done and discussed
Public API, Private methods and attributes¶
All methods and properties which are public API are marked with
@api. The public API is supported
for a longer period, and when a public API changes, this is clearly communicated in the
Release Notes of a version.
On the contrary, we prefix
private methods and attributes with an underscore. The user of an API should never
override or call methods
private methods as they are not meant for him to be overridden.
There’s also a type in between: methods which are not
private but do not have a
@api annotation. They
can be safely overridden by the user, and he should not experience any unwanted behavior. Still, the names or
functionality of these methods can change without notice between releases.
In the long run, all of these methods should become part of the public API, as soon as they are proven in real
To sum it up, we have three types of methods/properties:
@apimethods: Public API, the user of the object can rely on the functionality to be stable, changes in @api are clearly communicated
@apibut also not private: The user can use it, but needs to be aware the method might still change.
- private (prefixed with
_): The user should never ever call or access this. Very strange things might happen.
When to use a new file¶
As we use requirejs for loading dependencies we came up with the following guidelines for creating a new file:
- Classes using a template include using the
!textplugin should be in a separate file
- If a class is extended by another class, then it should be in a separate file so it can be easily loaded as dependency
- If a class is huge, and affecting readability of the definition file, then it should be moved to a single file
- It has preference to keep classes grouped together, so classes with just a few lines stay grouped together, so if none of the above is true the classes stays in the main file.