A good name is to be chosen rather than great riches...

Ruby is a high-level programming language that was created in the 1990’s. It is an object-oriented language and is frequently used in backend development. I am a student at Flatiron school, and our introduction to the backend was made using Ruby. One of the challenges my group ran into while doing our phase project was how to name our different objects. A situation came up where I realized that naming conventions should not just apply to those working on the project, but they must make sense to people outside of that project. Names should also be “readable”. Your naming convention should use real words and phrases as much as possible.
Most important, in my opinion, is that your names be descriptive. Your names should tell the reader what an object is, and where it fits into the hierarchy. A series of variables named “c1, c2, c3”, etc are obviously related. It’s good that you can tell that these variables are related, but that doesn’t tell us anything else about them. Are they also related to the variables named “b*”? You can’t really tell from the name. If c1 refers to the name of a city, then the variable could be called city, or cityName. If c1 is an array that incorporates data about a city, perhaps cityData would be good. Or if there are multiple data sets, maybe cityDemographics, cityGovernment and cityMeteorology would be more appropriate. It is also entirely possible that “city” is too generic, and cityDemographics should actually be anytownDemographics to differentiate it from other cities.
While descriptiveness is crucial, there are several smaller concepts that can also make or break your naming convention. While descriptiveness is the most important thing, it is not the only thing. If you require an entire line of code to describe a variable, you may need to revisit how your code is organized and rethink the names! A name should be just long enough to be descriptive enough. Consistency is also an important concept in naming. The way you name objects should be similar throughout your project. A reviewer jumping around in your code should not see a jarring difference from component to component. Your naming convention should stay professional. We are all guilty of using nicknames and funny words for objects, but code should be written with a view to being reviewed by managers with no sense of humor. Also, production code with unprofessional references to the project will not endear the customer to the development team.
There is too much content on naming conventions to cover in a blog post. This is a simple post meant to cover a few basics, and give a beginner and idea of what good names would entail and pitfalls to avoid. Starting now using a descriptive and professional naming convention will benefit you later in your career. Even if you work by yourself, using a good naming convention can help if you need to bring in help. In short, everybody needs to use good names!