Coding conventions and styles for Ruby in a Nutshell
Coding Conventions are very important part of Software Development. Following a specific coding convention just makes life of a developer working on your code much easier.
While some conventions are necessary for readability, for example, keeping the length of a line of code well within the size of the screen so that we don’t have to scroll both horizontally and vertically after each line.
Given below are some very common and neglected scenario where we should use this convention to enhance readability and also performance in some cases. Most of us have been through Ruby/Rails style-guides, so I am only gonna present points in a very sharp and “to the point” manner,some of these practices are to be adopted and some that need to be avoided.
1. Ternary operators must not be nested. We can use if/else constructs in some of the cases like:
# bad some_condition ? (nested_condition ? nested_something : nested_something_else) : something_else
# good if some_condition nested_condition ? nested_something : nested_something_else else something_else end
2.(i) Prefer {…} over do…end for single-line blocks.
(ii) Avoiding use of {…} for multi-line blocks.
names = ["Venkat", "Sonu", "Kurian"]
# good names.each {|name|puts name }
# bad names.each do|name| puts name end
# good names.select {|name|name.start_with?(“S”) }.map {|name|name.upcase }
# bad names.select do|name| name.start_with?(“S”) end.map {|name|name.upcase }
3.(i) Use %w for defining array of words.
# bad STATES = ['one', 'two', 'three']
# good STATES = %w(one two three)
(ii) Use %i for defining array of symols.
# bad STATES = [:one, :two, :three]
# good STATES = %i(one two three)
(iii) While accessing the first or last element of an array, use array.first or array.last over array[0] or array[-1].
(iv) While dealing with unique elements, use Set instead of Array . Set implements a collection of unordered values with no duplicates.
Set is a hybrid of Array’s intuitive inter-operation facilities and Hash’s fast lookup.
The difference between Array and Set is that, an array is an ordered list of key/value pair where keys(index) are always integer and the values are objects. Whereas a set is an un-ordered pool of unique objects.
4.(i) Use symbols instead of strings as hash keys.
# bad hash = { ‘one’ => 1, ‘two’ => 2, ‘three’ => 3 }
# good
hash = { one: 1, two: 2, three: 3 }
(ii) Avoid the use of mutable objects as hash keys.
Use the hash literal syntax when your hash keys are symbols.
# bad hash = {:one => 1, :two => 2, :three => 3 }
# good hash = { one: 1, two: 2, three: 3 }
(iii) Use Hash#key? instead of Hash#has_key? and Hash#value? instead of Hash#has_value?.
# bad hash.has_key?(:test) hash.has_value?(value)
# good hash.key?(:test) hash.value?(value)
(iv) Use Hash#fetch when dealing with hash keys that should be present.
heroes = { batman: ‘Bruce Wayne’, superman: ‘Clark Kent’ }
# bad – if we make a mistake we might not spot it right away heroes[:batman] # => “Bruce Wayne” heroes[:supermann] # => nil
# good – fetch raises a KeyError making the problem obvious heroes.fetch(:supermann)
(v) Introduce default values for hash keys via Hash#fetch as opposed to using custom logic.
batman = { name: ‘Bruce Wayne’, is_evil: false }
# bad – if we just use || operator with falsy value we won’t get the expected result
batman[:is_evil] || true # => true
# good – fetch work correctly with falsy values
batman.fetch(:is_evil, true) # => false
(vi) Prefer the use of the block instead of the default value in Hash#fetch.
batman = { name: ‘Bruce Wayne’ }
# bad – if we use the default value, we eager evaluate it, so it can slow the program down if done multiple times batman.fetch(:powers, get_batman_powers) # get_batman_powers is an expensive call
# good – blocks are lazy evaluated, so only triggered in case of KeyError exception batman.fetch(:powers) { get_batman_powers }
These are some very common and very useful convention that can enhance readability of your code and would help in maintaining, understanding the software design easily and quickly.
reference-https://github.com/bbatsov/ruby-style-guide,https://github.com/bbatsov/rails-style-guide