Good Naming Conventions

Maintaining good naming conventions aren’t just good programming practice, it also shows common courtesy for fellow programmers and yourself. You may be asking yourself “Why is this so important?” Well one day, hopefully, you will be working with other programmers in the same field, or will have to modify another person’s code or vice versa. Having the ability to clearly read the code is a direct reflection of the person who wrote it.

If the person coding a particular application happens to be lazy, they’re code will likely be sloppy, haphazard and hard to maintain. This is never good for too many reasons to list here in a comprehensible manner. This also makes the programmer appear inferior like they’ve never even seen good clean code before. This may be entirely untrue, but sometimes appearances can be deceiving.

Besides having clean, well working code, you should always stick to a well regimented naming convention. Sometimes this can be a little extra work, but it is work that will pay off in the long run. Here are a few examples of good naming conventions. I’m sure there are more, but for the brevity of this article, we’ll just go through a few.

Always have meaningful names. If you are trying to instantiate a class named “Drafts”, you wouldn’t want the containing variable to be “foo.” It doesn’t make sense. If you plan on working on a new draft of something, use “draft” for the variable. Or, lets say you are working on a newspaper. Use “newsPaper” for the variable. That way, as you flow through the code, you don’t have to try and remember what class was instantiated to begin with.

Maintain naming conventions throughout the entire project. Decide early on if you are going to go with underscores, hyphens, camelCase or any variation thereof. This may seem redundant, but I’ve seen code where they apparently just went with whatever they felt like that day. If you are going to mix styles, and use underscores for variables, and camelCase for classes, then make sure you follow this throughout the life of the project. If you are going to mix it up, at least leave a “README” somewhere in the base directory for the next programmer to find.

Make sure that your directory trees also have a good naming convention associated with them. Try to avoid using the same name in different parts of the application. This is just confusing. If you need to have a directory with the same type of folder name, append the name with the section that folder is in. For instance, you keep logs, like every good programmer, and you maintain these logs in different parts of the application for one reason or another. Don’t just have a folder named “logs” in 3 different parts of your application. Append the section to the folder. “main_logs”, “back_logs”, “user_logs.” These are all great names, and lets you know what those logs are part of.

Keep item names short. There really is no reason to have a variable/class/method/directory name like “PostTpLShopProductFzP”. That’s just confusing. Try to keep the name as short and as poignant as possible.”PostShopProduct”, “PShopProduct”, or “ShopProduct” are all acceptable in return. Wouldn’t you rather write “ShopProduct” over “PostTpLShopProductFzP”? Imagine having to write that several times. Your chances of botching that up go up every time you do so. Now I’m sure there are justifiable reasons that you sometimes need to have a name like this, but at all costs, try to avoid it if possible.

For the sake of this article, I tried to make the conventions as ambiguous as possible. Of course each language will have it’s own syntactical correctness associated with it. The purpose was to simply give a few helpful pointers on how to use good naming conventions and why they are important.

This entry was posted in Inspiration and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply