Programming Practices Part 1

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – Martin Golding

While coding, majority of us just focuses on the aspect of solving the problem at hand, but very few focuses on the aspect that we should not just code in the manner that it solves our problem most efficiently, but also can be reused and extended in the future, and not just by the original programmer but by others as well. In this blog, I’ll be focusing on this aspect of programming. I should also mention that there are no strict rules or a specific convention of programming over which everyone agrees, there are numerous school of thoughts about them. But there are certain things over which everyone agrees, and I will be sharing them with you as they were shared with me by a veteran developer.

Naming conventions:

The foremost important thing while programming is the naming convention, and not just of variables, but of functions, classes, objects and everything else. The sole reason behind it is that the functionality and the purpose of our functions and variables should be reflected in the name. This enables the programmer to not just understand the code in better sense, but to optimize and extend it with least effort, without having to go through the code again and again to understand the reason and functionality behind the specific function or the purpose of variable.

That being said, let’s discuss how to name our functions and variables in most appropriate manner.

  • We should either follow Camel Casing or Pascal casing throughout code, never the mixture of both.
  • One of the best practice while naming is that we should follow the naming convention of the language of our framework, instead of following our own. To give an example, in .Net framework the first letter of the name is capitalized, where as in Angular.Js it’s not. So instead of using .Net’s convention in Angular.Js or otherway around, we should stick by the native convention of the framework. The reason behind this is that it keeps the consistency between our code and the native code, and makes the reusability of 3rd party code easy as well.
  • While naming a variable, we should always keep this in mind that the name should reflect what will this variable represent in the code. To give a quick example, if we want to have a variable to keep the user name, then we should name it as UserName or userName or username, as it shows that this variable holds the user name.
  • The name of the class should not just be meaningful, but should also start with capital letter, and name of its object with small letter, never other way around.
  • While naming a function, we should first see whether the function is performing an action on or for something, or whether it’s a helper or standalone function. By standalone functions, I am referring to functions such as Main, Load and other basic functions. In-case of standalone functions, the naming convention should follow as per the framework convention, where as in case of the functions which performs some action or manipulate the variables, they should not just follow the naming convention of the language, but also be broken down in two parts. The first part of function name should represent the action of our function, and second part should represent that on what is that function doing the action. This can be elaborated by naming the function which is used to retrieve users from database. Such a function should be named as GetUsers() in .Net framework or getUsers() in Angular.Js. Similarly, while working in Java or Objective-C, their native convention would be followed.
  • The use of underscore “_” should be reserved for private variables only, and some people even say that it should be only used for private readonly variables. Underscore shouldn’t be used as an alternative of space “ “ in variable or function names.
  • There are plugins for almost every major IDE which notifies the programmer in-case any of the naming convention is not being followed. I strongly recommend the readers to explore into them and utilize them as much as they can, and for Visual Studio users, “ReSharper” plugin is extremely recommended.

Refactoring the code:

There is a saying in programming paradigm that the code with least chances of error is the code with least number of lines. The rule of thumb in programming is that if a certain chunk of code is present in more than one place, a separate function should be created containing this chunk of code and this function should be called respectively. This not only minimizes the code and make it more efficient, but also makes testing of code easy. More-over, let’s discuss few conventions for refactoring purposes

  • We should try to make our functions as much generic as possible. By making a function generic, we can reuse them through not only multiple classes, but also across different programs. To elaborate it further, let’s have a scenario where we have to create multiple functions to retrieve data from database depending upon the column name, so instead of creating multiple functions we can create a one function which takes column name and value as parameters and retrieve data according to the them.
  • We should try to keep our functions as compact as possible. According to some programmers, if a function exceeds more than 15 lines of code, then it’s time to split it into parts. This helps us to keep the more organized, and also allows us to extend it for reusability.
  • We should create helper functions; Helper functions are those functions which are called from another function to do a specific task and then return the execution to the previous function. This again, keeps our functions compact and manageable.

These are just two of the numerous techniques of writing an efficient and optimized code. We will discuss the others in this series of programming practices as well, and once again, there are no hard rules in programming, in the end, it’s all about our own preferences BUT, always code in the manner that if you look at it after 6 months, you can easily understand it and so can other developers!

One thought on “Programming Practices Part 1

Leave a comment