The more meaningful names we use in code, the easier it is to understand what the code is doing when we return to the code months or years later (to debug or develop further). If the code is easier to understand later, it will also be more understandable for someone else who works on the code at a later date. Also, meaningful names allow the code to do its own commenting; the clearer the names, the fewer comments are required to remind ourselves what objects and properties do.

For example, when I was taught trigonometry at school, I was taught the following equation to describe the relationship between the lengths of the sides of a right angled triangle:

a2 = b2 + c2
Where a is the length of the longest side (the hypotenuse),b, and c are the lengths of the other two sides.

While writing the equation, it made it easier to simplify the length parameters into the single letter representations a, b, and c. However, when learning the equation, not only had I to remember the form of the equation, but also what each letter represented. So, remembering one equation required two memory processes: remember the equation and remember the where statement that described how each parameter was mapped to the right letter. In isolation from the where clause, it can be difficult to determine what the equation represented.

In coding, the benefit of shortening a parameter name is not as great as it is when making calculations on paper. In fact, the advantages of lengthening the name usually outweigh those of shortening it, if the lengthening is used to make the name clearer. Look at how the representation below of the same equation is easier to understand without defining a where statement:

long_side_length^2 = medium_side_length^2 + short_side_length^2

As the parameter names now describe the parameter itself, we no longer need a where clause.

The names also demonstrate how the simple use of underscores can be used to combine a series of words into a single text string in a way that makes them easy to read. An alternative is to use"camel case" where a capital letter indicates the start of each sub-word, so long_side_length becomes LongSideLength.

As names are often made up from a combination of words, it is always a good idea to develop a simple set of rules to help keep each name of a consistent structure. For example, if in the triangle equation the sides were labeled side_1, side_2, and three_side, someone else reading the code would have to wonder what it was about the third side that led to it being named using a different convention to the first two sides. Being haphazard in naming objects and parameters leads to unnecessary confusion.

A naming convention will also allow you to take a few shortcuts in names. For example, someone describing objects on a map of London may want to describe both Green Park (an area of London) and some parks that are green. They could use long names of green_park_the_district and park_that_is_green. However, if they used

a convention that:

Ruby on Rails has a set of its own naming conventions and complying with these conventions simplifies many tasks. Therefore, this is a good point to introduce some of these conventions as they can be used here to demonstrate some of the advantages of using a consistent naming convention. Also, it is probably not a good idea to describe many more naming conventions if they do not comply with the Ruby on Rails conventions and have to be abandoned later.

if item.in_stock?

# this method returns a copy of array "items" as a new object
sorted_items = items.sort
# whereas this method alters the object "items" itself
items.sort!

def hello?
return "Hello"
end