JavaScript The Early Lessons: Naming Conventions

Trig
4 min readApr 6, 2022

My articles are aimed at those people just starting out on their webdev journey, I am myself a Jr WebDev (aged 42, say what !) and I want to share some of the things I have learnt and wish I was taught at the very beginning of my journey.

Today I’m going to share information on naming conventions and how imperative it is to improve the readability of your code.

From the very first day, we learn how to code we have it pushed at us from all angles, with comments like, Don’t Repeat Yourself (DRY), keep your code as small as possible and training material that uses bad naming conventions, so its no surprise that as Junior Developer we often stall over what to call something. So here are some best practices you should use immediately no matter where you are in your developer journey.

1. Style

Each language out there has its preferred method for writing names, such as ‘PascalCase’ | ‘kebab-case’ | ‘snake_case’ | ‘camelCase’. Since we are talking about JavaScript, we should all be aware that camelCase is the preferred method. For example:

const name = ‘Trig’
const userName = ‘Trig’
const usersNameIs = ‘Trig’
// ….you get the picture

2. Do Not Use Single Letter Names

They are meaningless and really hold no benefit to you or anyone else trying to review or work on your code. Remember, we don’t want to dissect the code just to learn what a variable is there for.

// bad!
const x = ‘Trig’
// good!
const userName = ‘Trig’

3. Do Not Abbreviate (in most situations)

This is very similar to the above point, maybe there are abbreviations that are commonly used, maybe they are understandable, maybe they wouldn’t cause any major issues. This is, of course, true but as developers, we are part of an international community and many companies employ or outsource to people whose native language may not be English. So please always be clear from the get-go it's just courteous for the next developer that will look at your code.

// bad!
const strName = ‘Trig’
/* What does 'str' mean? ‘Straw’ | ‘String’ | ‘Strong’ | ‘Store’ */// good! I clearly see what you mean
const storeName = ‘Trig’

Now there are ‘certain’ abbreviations and acronyms that you wouldn’t apply the above rule and it is your job as a good developer to decide the most appropriate path, for instance:

const userId = 5654const userUrl = ‘https://mysite.com’

Both of the above are perfectly fine, no developer would expect to see a name that states `userUniformResourceLocators`. 😊

Up to this point, we have only spoken about variables but what about functions?

Well, the same rules apply but the name of a function should tell us what is its purpose.

4. What Is My Purpose

As a rule of thumb, it's often a good idea to prefix any function name with a verb but whatever you do it should explain what its purpose is. For instance:

function nameData(){
// what is name data and what am I doing with it?
}
function getNameData() {
// ok we are getting data but what is that data?
}
function getUserNamesFromDatabase() {
// ok I understand but is quite a long name, can we improve it?
}
function getUserNames() {
// Perfect!
}

As we can see a clear concise name, even if it is a few extra characters will save us a lot of time during the development process.

When thinking about what to call your variables or functions the golden rule is simple, ‘Don’t overthink it!’

Summary

I was told by some senior developers, that a good developer will be able to leverage the naming conventions in a way that ‘comments’ in the codebase are no longer required or kept to an absolute minimum. This is the dream for all us junior devs but if you need to add a comment don’t stress over it, but do ask yourself the question ‘why am I writing this?’ ‘could my variable and functions be renamed to make this clearer?’

Note:

There are of course other situations in which the above rules may not apply such as global variables, classes, components etc, but the purpose of these articles is not to get bogged down in overly complex examples, I’m sharing my experiences from the point of view of a Jr Dev with others on a similar level.

If you liked this article please give me a clap and feel free to follow me and we can continue our journey to Senior Dev together. 👍

--

--

Trig

The 40 Year Old Jr WebDev // Sharing the things I have learnt and wish I knew earlier! // All things WebDev! // Helping other Junior WebDevs.