Top 10 programming habits that make your code smell
Top 10 programming habits that make your code smell
No one likes smelly code, because they are the leading reason for the poor code quality of software. Smells make it hard for systems to maintain and evolve. Manually finding these code smells can be tricky sometimes. Bad habits are hard to lose, even for good developers. A good developer is the one who focuses on code quality and hates code smells. But code smells make their way into your program even if you don’t mean it, because of some bad programming habits.
Detecting code smells sometimes is tricky, but most of the time it is a more straightforward process. So what type of code smells do we create the most while programming? According to a 2018 survey on code smell, God Class is the code smell detected the most appearing in almost 55% of all projects.
God class is a class-type code smell that is formed when a class is doing too much work and impasses the single responsibility principle. The second most detected code smell is Feature Envy Class or Method. This happens when a class or method is more interested in the class other than what its actually in and it makes up for over 30% of all codes. Following these, smells like Shotgun Surgery, Data Class, Long Method are other dominant smells that are detected. You can read more about all types of code smells and additional information on our blog, “Everything you need to know about code smells.”
What makes your code smell?
Not Today, Maybe Tomorrow
Procrastinators work by the tagline “Never put off till tomorrow what may be done the day after tomorrow just as well.” Well, It doesn’t work for programmers. Code Review is the ultimate check for finding code smells and is a comprehensive process with various checks.
Postponing fixing code smell is just an increasing problem for the future. When the project deadline arrives, code smell which looked like a problem for the developer at first will look permissible because of lack of time. This leaves your smelly code just what it was, smelly.
Lack of teamwork
Fixing smells is a complicated job, but more complex is finding all smells. It requires a team of developers with different strengths and learning to look into the code and point out a smell. Finding such a team is a challenging task. An alone developer might not find and fix the code leaving it smelly.
Apart from reviews, you need a team to run through the fixes of smell. Abandoning your plan and insisting on a solution that has a low probability of success can be riskier. Constant communication with peers on how you are building your software and getting feedback will increase the quality of your code.
Premature Optimization
Donald Knuth, writer of The Art of Computer Programming and also a computer science professor at Stanford University wrote that the real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times. Premature optimization is the root of all evil (or at least most of it) in programming. This quote, first published in the 1960s, still makes sense in the current world. With most developers using agile programming, fixes are just one click away, but they forget that instant fixes create more significant code smell in the form of god classes and duplicity.
Not being a teacher
There is a large pool of programming knowledge, more like an ocean that its sure that there is no one person that has covered it all. And you as a developer has the responsibility not just to write good code but also share what you’ve learned by doing so. Sharing experiences, errors fixed, and methods used you are increasing the knowledge of your teammates and hence the caliber of your team. Let them learn from you, and maybe feedback from someone will give you something to learn more
Over Attached to your code
We know that your software is your brainchild and sometimes brings out your emotions as well. But being overly attached to your code is harmful to its development. Just like a startup’s model changes with the feedback and criticism it receives, the same goes for your code. Developers who can’t take criticism about the design of their code are those who create and ignore smells. It’s just too dangerous to assume that just because you wrote it, it’ll be fantastic.
Hardcore Coders
Some coders like stepping into god mode while coding, take “Author of Code” too seriously and write hundreds of lines of code but end up writing just a few god classes. Coders who don’t follow organizational measures, be it time, structure or design end up creating smells like god line, large class, data clump, cyclomatic complexities, long method, and other such.
Lack of knowledge about the tradeoff
Just because you used one program or method before and it showed excellent results doesn’t mean that the same program would show excellent results again in other software. Developers need to understand the tradeoff between design and applications. Every method works differently in different codes and finding the one with better design compatibility should be the first choice, which is something developers do not perform and end up giving birth to smells.
Resolving Code Smells
You heard it right! Smelly codes are often introduced while fixing other smells. Some smell like a refused bequest, which is a subclass not using methods and data of superclass is resolved the rise to another smell – Parallel Inheritance Hierarchy. There is a fine line between resolving smells and creating smells, something that coders can’t figure out.
Focussing on manual work over a tool
The leading reason why developers ignored code review and code smell is that they lack time to do it. This happens when coders choose manual practices over automated code smell tools. Code smells are hard to fix and even harder to find without the help of the right code smell tools.
Not using the right tool
Continuing from the above point, the reason why developers choose the manual process is because they are not able to find a tool that can meet their demands. Many tools focus on one type of smell and not on all kinds. A developer using one such tool fixes that smell, but in the process creates more smells because incomplete tools don’t work line by line.
Conclusion
Habits are hard to change, but there is a way to avoid those bad habits. Using automated code smell tools that sniff out the smelly code and also gives suggestions on how to resolve it is one such way. Such a tool is CodeGrip, which is free to try made for developers and leaders who love quality codes. CodeGrip eliminates the need for a team by acting as the most knowledgeable reviewer. It reviews, points to smelly locations and offers suggestions for resolving smells as well. Apart from that, it keeps track of all changes and shows progress with parameters that are important, making it an all in one tool for code review and making your code fragrant, free of smells!
Sign up with Codegrip now to keep your projects free of Code Smells
Liked what you read? Subscribe and get fresh updates.
P.S. Don’t forget to share this post.
