Sonu Oommen         

  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. Some conventions are necessary for readability, a very simple example would be 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. So these are some of the practices 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

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

# good { |name| name.start_with?(“S”) }.map { |name| name.upcase }

# bad do |name|
name.start_with?(“S”) { |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

# good

(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

(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 could enhance readability and would help in maintaining, understanding the software design easily and quickly.