Naming conventions in Ruby language
The only real difficulties in programming are cache invalidation and naming things.
A naming convention is a set of rules for choosing the character sequence (or simply, name) to be used for identifiers which denote variables, types, functions, and other entities in source code and documentation. (Source)
Using a naming convention has following benefits:
- To reduce the effort needed to read and understand (anything, but in our specific case, source code.
- To enable code reviews to focus on more important issues than arguing over syntax and naming standards
- To enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences.
- To help improve the productivity among the team by following coding standards and reducing arguments over syntax and style.
Popular naming conventions in Ruby Community
Following are the few naming conventions one should know and are taken from Ruby community style guide). These guides are used to make Ruby code more readable, acceptable in the community.
These rules are not mandatory but by following these conventions you are helping others to understand your code quickly and in an efficient manner. |
CamelCase for Classes
Use CamelCase for classes and modules. (Keep acronyms like HTTP, RFC, XML uppercase).
# bad class names
Someclass
Some_Class
SomeXml
XmlSomething
# good class names
SomeClass
SomeXML
XMLSomething
Snake Case for Symbols, Methods and Variables
Use snake_case for symbols, methods and variables
# bad names
:'some symbol'
:SomeSymbol
:someSymbol
someVar = 5
someMethod
SomeMethod
# good names
:some_symbol
some_var = 5
some_method
Snake Case for file and directory name
Use snake_case for naming files and directories
# bad names
someDir/someFile.rb
SomeDir/SomeFile.rb
Some_Dir/Some_File.rb
# good names
some_dir/some_file.rb
Screaming Snake Case for Constants
Use SCREAMING_SNAKE_CASE for other constants (those that don’t refer to classes and modules).
# bad name
SomeConstant= 5
# good name
SOME_CONSTANT = 5
Identifiers with a Numeric Suffix
Do not separate numbers from letters on symbols, methods and variables.
# bad names
:some_sym_1
some_var_1 = 1
var_10 = 10
some_method_1
# good names
:some_sym1
some_var1 = 1
var10 = 10
some_method1
Using a number against a variable name in an argument list can subdue the importance of the order. If it is important that one is first and onother is really the second one, then accentuate that by using 'name_1, name_2' because it is important that the first name is first.
One Class per File
Aim to have just a single class/module per source file. Name the file name as the class/module, but replacing CamelCase with Snake_Case.
Appropriate suffix for method names
Question mark for method returning boolean value
The names of predicate methods (methods that return a boolean value) should end in a question mark (?
), i.e., Array#empty?
).
Methods that do not return a boolean, should not end in a question mark.
# bad
def even(value)
end
# good
def even?(value)
end
Dangerous Method Suffix
The names of potentially dangerous methods (methods that modify self or the arguments, exit!
(doesn’t run the finalizers like exit does), etc.) should end with an exclamation mark if there exists a safe version of that
dangerous method, or if the name itself does not communicate this clearly.
# bad - there is no matching 'safe' method
class Person
def update!
end
end
# good
class Person
def update
end
end
# good
class Person
def update!
end
def update
end
end
Check more here.
Avoid predicate Methods prefix
Avoid prefixing predicate methods with the auxiliary verbs such as is, does, or can or has.
These words are redundant and (mostly) inconsistent with the style of boolean methods in the Ruby core library, such as empty?
and include?
.
# bad
def is_tall?
end
def can_play_basketball?
end
def does_like_candy?
end
# good
def tall?
end
def basketball_player?
end
def likes_candy?
end
Unused Variables Prefix
Prefix with _
unused block parameters and local variables.
It’s also acceptable to use just _
(although it’s a bit less descriptive).
This convention is recognized by the Ruby interpreter and tools like RuboCop and will suppress their unused variable warnings.
# bad
result = hash.map { |k, v| v + 1 }
def something(x)
unused_var, used_var = something_else(x)
end
# good
result = hash.map { |_k, v| v + 1 }
def something(collection)
_unused_variable, used_variable = something_else(collection)
end
result = hash.map { |_, v| v + 1 }
def something(collection)
_, used_variable = something_else(collection)
end
Help me to improve Dhanu Sir.