#coding conventions

Since Java Strings cannot be changed once created, if we need to construct a Java String with one or more variable(s) included, then we can use the format method. #java #string #syntax #performance #garbageCollection

TIP: References Quick List Java: String.format Java: Formatter: Format String Syntax Hello, Maddie! – Fields and Simple String Formatting Table of Contents Table of ContentsIntroductionConcatenationString.formatformatConstants Vs. Instance VariablesAppending to Existing StringsSummary Introduction Once created, a Java String object cannot be modified. If any changes to a String value must…

Java boolean variable names need a bit of flexibility from the general variable naming rule, as they can also store state.

 TIP: References Quick List Google Style Guide: Naming Java Variables Java Reserved Keywords ASCII Character Set Nouns Abound! Java Parameter And Variable Names Table of Contents Table of ContentsIntroductionJava Boolean Variable NamesSummary Introduction In Java, Boolean variables don’t strictly follow the noun or noun phrases variable naming approach from the last post. Java Boolean…

Having a consistent naming convention for Java input parameters, local variables and instance/static field names can help readers more quickly understand what the code is doing. #java #syntax #naming #variables #fields

 TIP: References Quick List Google Style Guide: Naming Java Variables Java Reserved Keywords ASCII Character Set Table of Contents Table of ContentsIntroductionInput Parameter NamesLocal, Instance and Static Variable NamesConstant Variable NamesNon-Constant Variable NamesLoop CountersSummary Introduction In Java, class and instance variable names, as well as input parameter names are…

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.

Ruby Styleguide

https://github.com/styleguide/ruby

Ruby on Rails Coding Conventions

http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions

Two spaces, no tabs (for indentation).

No trailing whitespace. Blank lines should not have any spaces.

Indent after private/protected.

Prefer &&/|| over and/or.

Prefer class << self over self.method for class methods.

Use MyClass.my_method(my_arg) not my_method( my_arg ) or my_method my_arg.

Use a = b and not a=b.