Top 5 Code Smells Newbies Developers Could Easily Identify & Avoid

Following is one very popular image which has been used to represent time and again for representing code smells. I am doing it again. Apologies if this one is repeat for some of you. But the image nicely represents how to find if your code really smells. The code smells listed in this article would certainly lead to increase in WTF count 😉

For newbie developers, it has always remained a challenge to write code of great quality from day one. One of the primary concerns they have been found to have is following:

What kind of code could be termed as high quality code?

There are several characteristics of good quality code. However, a good starting point would be to write code which could be easily maintainable and usable (readable and understandable). Maintainability and Usability are two very important characteristic of software quality as per ISO 25000 as well. Two important features of a highly maintainable code are testability and reusability. Thus, the three key code quality that newbies could keep in mind are testability, reusability and usability.

Top 5 Code Smells Which are Easier to Identify & Avoid

If only newbies could watch following 5 areas (code smells) and avoid them, they would mostly end up with the code conforming to the requirements of testability, reusability and usability:

1. Long Classes: It would be good to keep a watch on number of lines of code (LOC) in the class. If it crosses more than 300 or so, you may want to check on the fact if the methods of the class are related and serving just one functionality our doing just one thing. This is in line with the famous SOLID principle namely Single Responsibility Principle. Another area to look at is if individual methods are getting longer enough whose detail is describe in next point related with long method. Having classes serving just one functionality is easier to change as there could be only one set of related reasons for which the class would be needed to change. Thus, these classes becomes greatly maintainable meaning testable and reusable. These classes can also be termed as cohesive classes.
2. Long Methods: If the LOC in a method increases more than 50-60, it is time to watch out and make sure that method is just doing one thing. Most of the times, methods get longer because of following two reasons:
   • Methods consist of block of codes performing multiple functionality which can also be classified as violation of “single responsibility principle”. In this case, one could consider extracting block of codes performing different functionality into different methods.
   • Methods consist of long conditional statements consisting of if-else statements which can again be extracted into different methods.
3. Long Conditionals Expressions: At times, methods get longer due to large number of conditional statements in the same method. This can also be explained in terms of McCabe Cyclomatic Complexity which can be calculated as number of conditional statement + 1. These conditional statements looks like if-else, while, for, switch etc.  If the cyclomatic complexity of a method becomes larger than 10 or so, it is time to watch out and see if these conditional expressions could be extracted into separate method. Long conditional expressions greatly reduces code usability that is code readability and understand-ability. More importantly, if you a unit testing freak, more the conditional statements in your method, more it becomes difficult to achieve a higher code coverage.
4. Long Parameter List: Newbies developers tend to create method with long parameter list that creates issue at later stage when many other methods have called these methods and there arises a need to add another parameter to the existing list. Once you see that parameter list of a method increases further than 4-5 parameters, it is time to examine whether these parameters are related and could be created as a parameter object and passed to methods as objects. This makes it easy to add further parameters to parameter object without the need to change the method signature and the code becomes greatly maintainable.
5. Vague Classes & Method Names: This one is very simple to identify. If you can not get a good name to name your classes and methods, be sure that you may be missing on business requirements which is supposed to be served by the method or class. Alternatively, for other developers, if the method and class names becomes difficult to understand, it is time to think through and come up with the name that could help developers to understand the functionality that is supposed to be served the method or the class.

You may want to check the refactoring patterns that could help you with tips to avoid these smells and write neat code.