Skip to content

Coding style guidelines

Raghav Jajodia edited this page Aug 10, 2017 · 2 revisions

Code style and conventions

Be consistent!

Look at the surrounding code, or a similar part of the project, and try to do the same thing. If you think the other code has actively bad style, fix it.

When in doubt, feel free to ask questions at Slack.

Linting

No linters added yet!

Translation tags

Bugheist now supports multiple languages. Remember to use translation tags wherever necessary.

More arbitrary style things

General

Indentation is four space characters for Python, JS and CSS. Indentation is two space characters for HTML templates.

We don't have an absolute hard limit on line length, but we should avoid extremely long lines. A general guideline is: refactor stuff to get it under 85 characters, unless that makes the code a lot uglier, in which case it's fine to go up to 120 or so.

Whitespace guidelines:

  • Put one space (or more for alignment) around binary arithmetic and equality operators.
  • Put one space around each part of the ternary operator.
  • Put one space between keywords like if and while and their associated open paren.
  • Put one space between the closing paren for if and while-like constructs and the opening curly brace. Put the curly brace on the same line unless doing otherwise improves readability.
  • Put no space before or after the open paren for function calls and no space before the close paren for function calls.
  • For the comma operator and colon operator in languages where it is used for inline dictionaries, put no space before it and at least one space after. Only use more than one space for alignment.

JavaScript

Don't use == and != because these operators perform type coercions, which can mask bugs. Always use === and !==.

End every statement with a semicolon.

Use

$(function () { ...

rather than

$(document).ready(function () { ...

HTML / CSS

Don't use the style= attribute. Instead, define logical classes and put your styles in external files such as style.css.

Don't use the tag name in a selector unless you have to. In other words, use .foo instead of span.foo. We shouldn't have to care if the tag type changes in the future.

Don't use inline event handlers (onclick=, etc. attributes). Instead, attach a jQuery event handler ($('#foo').on('click', function () {...})) when the DOM is ready (inside a $(function () {...}) block).

Use this format when you have the same block applying to multiple CSS styles (separate lines for each selector):

selector1,
selector2 {
};