Code style guide

hzr edited this page Sep 19, 2012 · 13 revisions
Clone this wiki locally

Opera Dragonfly code style guide

All new code should follow these style guidelines to pass code review. The guidelines are here to get more readable code. If your code gets more readable by breaking any of these rules, then by all means do it (if you can argue for it to whomever reviews your code). If something isn't covered by the guidelines, look at other code and then add it here.


  • Use UTF-8 with BOM.
  • Use UNIX newlines.
  • Limit the number of characters per line to something sane. 80 is generally good, but not a hard limit.
  • For string delimiters, quotation marks (") are preferred over apostrophes (').

File names

  • File names are all lowercase. Underscores can be used for readability.
  • File names for a component are generally of the form <component>_view.js, <component>_style.css and so on.



  • All new code should be written to work in strict mode. The first line of every JavaScript file should be "use strict".
  • One var declaration on each line, declared in the block where it's used.
  • When converting the type of a value, use the constructor as a function. For example, instead of ""+1, use String(1) and instead of !!foo, use Boolean(foo).


  • Two spaces for indentation.
  • One newline between methods, if statements and so on.
  • One space on each side of an operator. (There are exceptions though, e.g. the comma operator and the grouping operator).
  • No whitespace immediately inside parentheses, braces, brackets (except newlines).
  • Whitespace between the keyword in a statement (e.g. if, switch) and the open parenthesis.
  • Cases inside a switch statement may be lined up with the braces of the switch statement.
  • Other than that, code can be lined up in any way for readability (but in general, don't line up assignments for example).


  • Always use braces.
    • An exception is for one-line if statements (one physical line), where they may be skipped.
  • Braces go on the next line.
    • Exceptions to this rule is where the code would look confusing, e.g. for function expressions used as a function argument.


  • Classes are camelcase with initial capital letter.
  • Constants are capital letters and underscores.
  • All other names are lowercase with underscores.
  • Private members are prefixed with an underscore.
  • Reserved words can be used if suffixed with an underscore (thus not making them reserved anymore).
  • Globals other than classes should be prefixed with window.. (They should however not be created in the first place.) Native objects (e.g. NaN or parseInt) should never be prefixed. Host objects can optionally be prefixed (e.g. window.setTimeout).


  • Classes are defined like so (any class that can be subclassed should have an _init method, so in general it should be included):
 * @constructor
 * @extends BaseClass
var MyClass = function(arg)
  this._init = function(arg)
    // ...

  // ...


MyClass.prototype = new BaseClass();

MyClass.my_static_method = function() {};

MyClass.MY_CONSTANT = 1;
  • All methods are set as methods on the object or on the prototype (i.e. no var m = function() {} inside classes). Private methods are (as mentioned above) prefixed with an underscore.
  • Don't use singletons. Pass in instances to other classes.
  • Super class methods are called like so:
this._init = function(arg1, arg2)
{, arg1, arg2);

This has the disadvantage of being quite verbose and having to explicitly know the super class, bit it's one of those limitations.


  • Indentation is two spaces.
  • One space between property and value.
  • One declaration per line.
  • Braces on new lines.
  • One newline after each rule.
  • The integer part in a decimal fraction must not be dropped if it's 0. 0.1 is correct, .1 is not.
  • The preferred color format is hex. If alpha needs to be specified, use RGBA.
  • Omit the length unit when the value is 0, e.g. padding: 0 instead of padding: 0px.
  • Always include quotation marks even if they can be omitted. This applies to e.g. URLs in url() and values in attribute selectors, e.g.:
  background-image: url("schwupdiwups.png");
  • One simple selector per line, e.g.:
  color: red;
  • Multiple values and arguments to functions should be lined up if they are long, e.g.:
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.2),
              0 1px 1px rgba(0, 0, 0, 0.1);
  background-image: linear-gradient(0deg,
                                    red 1px,
                                    blue 1px);

Performance considerations for selectors

  • The last part of any selector (not including pseudo classes and pseudo element) must be a class name (unless there are good reasons not to).
  • Avoid two class names in the same simple selector. Instead do namespacing by using a longer class name. E.g. do .drag-handle-right instead of .drag-handle.right.
  • In general, try to use only class names, and preferably only one. Namespace them with the name of the view if they are unique to that view.