Ruby Style Guide

# ruby style
# how to concision

# CamelCase for module and class names
#
OneModule
OneClass

# snake_case for variables, methods, and
symbols
#
one_variable
is_a_method?
now_a_method!
:a_symbol

# CONSTANTS are variables that don't vary for
# the duration of a program, they should be written
# in SCREAMING_SNAKE_CASE
#
LOUD_AND_PROUD_CONSTANT = "global
access"
# class and module names in ruby are constants
# we write their names in camel case by convention
#
class CamelCase

# avoid single letter variables except for
# when their use is very clear
#
num = (1..100).reverse_each {|x| puts x }

# an exclamation mark is used by convention
# for methods that change the state of the
# object they are called on.
# these are called 'dangerous methods'
#
strings.mutate_in_ruby! # good to know

# a question mark is used by convention
# for methods that return true or false,
# these are called 'predicate methods'
#
assertion.is_naming_convention? # true

# an equals sign is used at the end of
# method names that make assignments
# these are called 'setter methods’
# and is SYNTACTIC
#
class SomeClass
def setter=( value )
@instance_variable = value
end
end

# setter methods can be called with
# simplified syntax (syntactic sugar)
#
instance = SomeClass.new
instance.setter=(new_value) # can do
instance.setter = new_value # should do
# there’s a lot of this in Rails

# a common mistake is trying to use
# it inside class definitions without
# specifying the object
#
class SomeClass
def setter=( value )
@instance_variable = value
end
instance_variable = value # doesn’t work and
instance_variable=(value) # is trying to do this
self.instance_variable = value # do this
end

# with setters inside a class, just remember
that:
#
<<RULE
Assignment expressions will only invoke a
setter method when invoked through an
object.
RULE

ruby.can_use_semicolons? # true
# but please don't unless you really
# want more than one statement per line
#
can_be tidy; can_also_be obfuscated;

# whitespace
# indent with 2 spaces
# don't use tabs... ever
# always put whitespace around the
# assignment operator
#
foo = 1

# unless you're setting default
# method parameters
#
def foo( baz=2 )
puts 2 ** baz
end

# use underscores to make long
# numbers more readable
#
10000000000 # how many zeros?
10_000_000_000 # keeps fingers off the screen

DoNot::call::methods::with_double_colons
# yes, you can do it
#
a = 256::to_s::reverse!::to_i * 2 # 1304
# but it’s usually thought of as constant access
#
SomeObject::ITS_CONSTANT

# when block commenting it is nice to
# leave a blank line before the actual
# code for the sake of readability
#
def apprehend( archibald )
archibald.get_him
end

# for strings with lots of odd characters
# it can be better to use the alternative
# string literal syntax to avoid using escapes
#
string = %q[<a href="javascript:method('call')">js?</a>]
# resolves to "<a
href="javascript:method('call')">js?</a>"

# if you have a really big string it
# can be better to define it like so
#
big_string = <<delimiter
]})@#$^UHEOIG(FKALSNC
this is just one string
and that is totally okay
()@))_-p[[}{P{{p[]}{[
delimiter

# this is arguably inferior:
#
big_string = "this string right here " +
" be concatenated with this one" +
" aaaaand this one too" +
" all these concatenations" +
" are all a bit tiresome, no?"

# << or <<- can also be useful for
# passing big strings as arguments
#
DoesTheObjectMatter.new(:value => <<-eos
don't worry about this it's all
just one big string, no one is
the wiser
eos
this = :no_longer_the_above_string

# passing arguments with hash-like syntax
# can save other people's time when reading
# your code:
#
divide(1, 3) # which is which?
divide(:num => 1, :denom => 3) # clearer

# you can designate code blocks two ways.
# the conventional way for multi-liners is with
#
do
...
end

# you can also use '{ .. }' but please
# only use those for single-line blocks
#
single_line_block = (1..1000).map {|x| x**2 }

# procs and lambdas can be helpful for keeping
# your code DRY, among myriad other things.
# use the lambda literal syntax (not keyword)
# for good style
#
anonymous_method = ->( p_one, p_two ) do
p_one + " and " + p_two
end

# 'and', 'or' are seldom used by convention
# and can do unexpected things because they
# bind differently than &&, ||
#
puts nil || "rainier" # this prints "rainier"
puts nil or "rainier" # this prints nil

# why? the later parses to:
#
puts (nil) or "rainier"
# the former to:
#
puts ( nil || "rainier" )

# one-line 'if' statements
# works
#
variable = if test then pos_result else neg_result
end
# better
#
variable = test ? pos_result : neg_result

# nest 'if' like this:
#
if test
nest_test ? nest_result : nest_other_result
else
first_layer_result
end
# deeply nested 'if' statements are generally
# considered to be bad style

# use 'unless' instead of negative 'if'
#
something.action if !test # questionable
something.action unless test # better
# but never use 'unless' with 'else'
# use an 'if' instead.

# but never use 'unless'
with 'else'
# use an 'if' instead
# similar situation with while/until
#
something.action while !test # no
something.action until test # yes

# use ||= to freely initialize variables
# to avoid unnecessary 'if' statements
#
variable ||= 'kenny wheeler'

# if the first argument begins with a parentheses
# then use parentheses in method invocation
# this is a common source of consternation.
#
method ( 3 + 2 ) % 2 # ambiguous
method(( 3 + 2 ) % 2) # unambiguous
(method( 3 + 2 ) % 2) # unambiguous

gem install rubocop
<<-arbitrary_string_delimiter
from the README:
rubocop is a Ruby code style checker based on the
Ruby Style Guide, which is available on github:
https://github.com/bbatsov/ruby-style-guide
rubocop is pretty strict, but can be useful
arbitrary_string_delimiter

Ruby Style Guide

More Related Content

Similar to Ruby Style Guide

Recently uploaded

Ruby Style Guide