What does a name mean in Ruby?

Throughout my first few weeks of learning Ruby, I’ve been bombarded with a ton of new information. While a student at Flatiron School’s software engineering boot-camp, we are given a ton of new information everyday, often compounding on the prior day’s lessons. I began to notice myself building a defense mechanism of only allowing myself to focus on the major topics, not bothering to master minute details like naming conventions. As we progressed I felt my technical skill growing, but I was often given feedback that the names of my variables and methods could use some work. Admittedly, at first I was kind of annoyed by this. If my code worked, who cared that I named something “i” instead of the name of the class I was iterating through? Why did it mater? As we dove deeper into Ruby and began working with Active Record, I began to notice small patterns in naming that could either break or make a line of code. It was only then where I saw how powerful names could actually be in Ruby. Here I am now, trying to break myself of bad naming habits, and maybe warning you before it’s too late.

So why are names so important in Ruby? Well, why are they important anywhere? Names are identifiers. They give us information. They let you know what to expect. If a variable was named “books” in Ruby, you would expect the variable in some way to hold information regarding books. The name is a representation of the information that is being held within the variable. In order to communicate with developers who are looking at your code weeks, months or even years in the future, it is important to have clearly readable names for your objects. This helps provide insight for the future devs on what exactly your code is trying to accomplish. It would be extremely frustrating for a developer to sit down and try and process line after line of complex code where a variable named books was actually pointing to information about fish in the pacific ocean. For your sake and your colleagues sake, name well!

So what makes a good name? Like I said earlier, you want to name your objects as a representation of what you are doing. In Ruby, you can think of variables and other objects, like Class instances, as nouns. They are objects that are describing information. Your methods are verbs. They are acting on these objects and manipulating them (shoutout to http://rubylearning.com/ for highlighting this association!) We can even see this type of interaction when looking into built in methods of the language. Take for instance the select enumerator. Well what is it doing? It’s iterating through a particular data set and SELECTING the instances that hold a truthy value. It has a name that lets you know EXACTLY what it is doing. When creating your own custom methods, keep in mind this noun to verb relationship! Another important thing to keep in mind when deciding on what to name your latest method or variable, is the relationship it holds with anything that it might interact with. If you are creating an association method, linking two classes together, your name of the method should reflect this. If the object that you are interacting with is a singular instance of a particular class, you should probably not pluralize its name. If you’re selecting multiple instances of a particular class, your method name should reflect that. It is important to reflect what kind of information you are navigating through. Let’s take a look at some code.

In the above lines of code we have a very simple select method that will return every number in the A array that has a value that is greater than four. This might be clear to me and people who have seen this enumerator before, but to a complete beginner it might be confusing what exactly is happening. So with the addition of powerful names, we can add clarity!

By now giving our array a specific name, our method a name that describes exactly what we are doing and giving our iteration variable a more clear description of what exactly it is we are iterating through, we are able to create more descriptive, more readable and some might even say more beautiful code.

There are all sorts of conventions for naming. When to use capitals, when to use camelCase, when to use snake_case, when to pluralize a word etc. These can often be found in documentation of a particular language/tool so I won’t go too much in depth on them. I will however, link to a few at the end of this post! The main takeaway I wanted with this post was to show how powerful being descriptive with your names can be. By simply refactoring your code with more readable language, you can directly increase the ease of which other developers are able to interact with your code. Whether it be a complete beginner or a seasoned vet, they will always appreciate an app with great names!

Ruby naming conventions:


ActiveRecord naming conventions:


Full-Stack Engineer