Difference between revisions of "Styleguide"

From diaspora* project wiki
Jump to: navigation, search
m
(Automatic local review)
Line 43: Line 43:
 
= Automatic local review =
 
= Automatic local review =
  
You can quickly check your feature branch for introduced violations with <tt>$ bin/pronto run -c upstream/develop</tt>
+
You can quickly check your feature branch for introduced violations with <tt>$ bin/pronto run -c upstream/develop</tt>.
 +
 
 +
Remember to commit files first though, uncommitted changes will not be checked.
  
 
[[Category:Developers]]
 
[[Category:Developers]]

Revision as of 01:23, 31 October 2015

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 JSHint 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 with $ bin/pronto run -c upstream/develop.

Remember to commit files first though, uncommitted changes will not be checked.