Styleguide

Please adhere to the following styleguides for your contributions. Transform existing code you touch to follow them.

Ruby

We follow bbatsov's styleguide for Ruby, with the following derivations and choices:

• Maximum line length is 120 characters.
• Always use raise, never use fail. Use abort to exit on a fatal error condition.
• No assignment in conditions, not even so called (safe = assignment).
• No enforced variable names for inject, use names that properly describe the data.
• Do not use Class.new to define exceptions, use the regular class keyword.
• Do not add spaces inside string interpolation, "a #{b} c" is valid, "a #{ b } c" is not.
• Do not do control flow with && and || outside conditionals. The only valid uses of && and || are in a condition and to compute a predicate that’s returned from a method.
• Do not add spaces around = when used to define default arguments in method definitions. def foo(a, b=c) is valid, def foo(a, b = c) is not.
• Default to using double quotes ("), only use single quotes (') when you want to use a double quote in your string. Use a percent literal if you want to use both in the string.
• Use the %i percent literal to define an array of symbols.
• Prefer Hash#has_key? and Hash#has_value? over Hash#key? and Hash#value?.
• Prefer String#% over Kernel#sprintf.
• Prefer inject over reduce.
• Do not put put a space between the opening brace and a block argument. foo {|a| } is valid, foo { |a| } is not.
• Do not put a space after the opening brace or before the closing brace of a hash literal. {foo: bar} is valid, { foo: bar } is not.
• Use Weirichs rule when deciding about about the block syntax to use.
• Use an appropriate name for the argument when defining an operator method, don't just default to other.

JavaScript

We use ESLint with our own config. Some of the most important rules are:

• All variable names have to use either camelCase style or UPPER_CASE with underscores.
• Always put curly braces around blocks in loops and conditionals.
• Use === and !== in favor of == and !=.
• Use two spaces per indentation level.
• Maximum line length is 120 characters.
• Use double quotes (")

SCSS

We use scss-lint with the default config. The scss-lint repo has some detailed information about the different linters.

Automatic local review

You can quickly check your feature branch for introduced violations.

Please do so before opening a pull request!

If you didn't commit your modifications: $ bin/pronto run -i

If you already committed your modifications: $ bin/pronto run -c upstream/develop.

Remember to update your local develop branch with git checkout develop && git pull upstream develop first.

Perform an automatic local review before pushing to your repo

If you tend to forget to perform the automatic local review before pushing to your repo, you can make Git perform it for you before doing some action. This tool is called a Git hook. For instance, you can make Git to run Pronto before any push to your repository and him fail if Pronto raises any warning.

To do so, go to the .git/hooks directory of your local repo, rename the file pre-push.sample to pre-push and and replace the content with:

  #!/bin/sh
  bin/pronto run --exit-code -c develop

Now, git will run Pronto any time you want to push to your diaspora Github repository and prevent you to push if Pronto raises warnings. If you want to ignore the Git hook, just add --no-verify to the git command.