DEV Community

Logan Johnson
Logan Johnson

Posted on • Updated on

Naming Conventions: Fix It.

Intro

Most newer people don't usually think of this often, and for that reason this post is dedicated to newer developers. Even if you are more seasoned, I hope that you are able to take some sort of value from this post, as I have seen some of this around my classes.

I have pulled a lot of this from my journal on my website for your enjoyment here because I believe more people should see it and be helped. Enjoy!


There are two things that come to mind when you open your own code after a long period of time.. or that even of another developer:

  1. WOW! That is so cool!
  2. Oh my goodness, who wrote this?!

We all would like to believe that our code looks like #1 -- but the honest truth if we can be honest with ourselves is: sometimes we'll look at our own stuff and thing about scenario #2.

I've composed some tips from multiple sources and people as well as myself, and I hope you find this useful! As far as crediting goes, it was people I met on platforms like discord and a few interpreted things off multiple searches on the internet.

Avoid abbreviation for things that are not commonly known

Things like "nav" or "hero" is okay because you or someone else nine times out of ten would know what this means.

Things like "blk" or "herr" is not okay because you or someone else will almost never know what this means unless they contributed and can remember what it was supposed to.

Make re-usable classes and names

When you type something out, write DRY (Don't Repeat Yourself) code. Make the classes and names re-usable, for example : "flex" could be used to throw flex display on something, but "flext-and-to-the-right" would not be good because now you're being super specific what that CSS class will do. Now if you need something on the left a few times, this will not serve you sell, and you'll end up making a longer** CSS file.

Try to avoid more than two words for a given name

Here's an example I found off a website in the past :

.button {
/* OK */
}

.dropdown-button {
/* still OK */
}

.dropdown-button-part-one {
/* Hmm, still ok, but will be unredable when adding children, for ex : */
}

.dropdown-button-part-one__button-admin {
/* Yikes !!! */
}

Make names reflect functionality

If your class sets the display to flex, you shouldn't name it: "super-awesome-block-element-thing" or even "hero-banner-box".. you should name it something related to what it does. This applies to all programming languages, and in my opinion, you should always be thinking of this when naming things.

Conclusion

These are just my opinion and suggestions to help you out long term, you do NOT have to use them, but take it for what its worth if it's any good to you.

Discussion (4)

Collapse
findlogan profile image
Logan Johnson Author

Thanks for taking some time to respond. I would like to firstly say that at the end, I did say that these are just my opinion on how naming conventions should be.

In environments, yeah something can be abbreviated and well known, but I was referring to something where you are not working in a team (either solo or a public project).

You mentioned: "Two" is just arbitrary. Why not three? Or four? Or seventeen?

There is no problem with using many, but I find 2-3 works best for me and other developers I know, and this keeps the classes more manageable in my opinion.

You're welcome to name things however you want, in the end of the day: it's still your code; i'm just here to hopefully help others who haven't necessarily developed their own naming rules yet.

Collapse
thoughtinstinct profile image
SparklingINsilence

Nice read, thanks for the tips.

Collapse
findlogan profile image
Logan Johnson Author

No problem!