Best Practises – Naming Standards Part Two

Part one saw us learn about good and bad naming for variables and method names, and the type of rules you should follow when deciding on names. In part two, we’re going to expand upon the naming standards for methods. Having a good method name is a start, but you need to take in to consideration the name for the parameters if there are any, as well as deciding on the number of parameters. Finally, we will cover how the purpose of the method will determine not only the name you give it, but also if the method logic itself needs to be reevaluated.

Let’s start with method parameters. You might argue that the naming rules for parameters is the same as variables, and to a certain extent you are right. They should follow a noun or adjective+noun format, and use the camelCase capitalisation that we learned about in the first article. But you should make sure that you give your parameters names that will match or at least closely resemble the variable that will be passed in to the method, this is based purely on a readability perspective. It will also benefit you when it comes to revisiting code after a period away and being able to understand what the code is doing.

I see a lot of tutorials online that recommend using underscores in parameter naming, which is a terrible idea. Not only does it look bad but it breaks a lot of rules of naming. Another misconception is to go against what I mentioned in the previous paragraph about keeping variables and parameters names matched or as similar as can be. A lot of places will argue that names should be different so it’s clear when you’re using a variable and when you’re using a parameter.

I personally think this is nonsense. If you follow good coding guidelines then this won’t be an issue. But I personally think having different names for both does the opposite and creates more confusion than poorly written code.

The next thing to mention is the number of parameters. There is no real rule to say how many you can have, but when readability suffers, you’re probably using too many. For example, having a method that takes 20 parameters is far too many and would mean that your method probably needs refactoring. Keep the number as low as possible, and look at why you’re using any extra parameters. If you’re using it as an easy way of adding functionality to a method then ask yourself if that’s the right thing to do?

If you’re using a lot of out variables, then again, have a think as to whether or not there is a better way of doing things? Just because there is no set rule to follow, it doesn’t mean that you shouldn’t adhere to being strict with yourself and thinking about clean and readable code.

Finally, I wanted to touch on the purpose of your method. I want to talk about this as this will indirectly affect the quality of your method naming.

A method name such as PlaceOrderAndCheckForConfirmationEmail() would imply that it’s not a single purpose method. When a method has more than one purpose, then by its very nature, it becomes very hard to name clearly. The name will also be long, and while the name used in our example is probably still just about verging on acceptable, it’s still not ideal.

If you find your method isn’t single purpose, then rather than struggle with the naming, it should be refactored. Going back to our example, the PlaceOrder and CheckForConfirmationEmail should be separated. This will benefit you in more than just better naming, it will also provide far more modularity with your code.

We’ve now covered the best practises for naming. Follow these simple guidelines and you’ll find your code will be far easier to read and will attract far less negative comments come code review time.