Showering your Mac does not help. I tried.
Introduction
I am so exited! We are standing at the beginning of a long journey to improve ourselves in respect to our code. This series of blog posts will bring us closer to all sorts of best practices in object oriented software development. It is not only dedicated to junior developers, but also to more experienced programmers who might find it interesting to look through the eyes of a junior (that’s me). How he thinks, how he tackles problems using OO principles and best practices, how he actually sees and understands the principles and practices. Maybe you, no matter if beginner or senior, have other experiences than I have made by myself and would solve the problems presented to you in a whole different way. Then please let us know! I am far away from calling myself a senior or even a good programmer. I look at myself as a lifelong junior who improves day by day. So hopefully we can make this fun for all sorts of developers and share our experiences. If you are interested in the fact of why I started this blog, please have a look at my motivation.
Today I will talk about signs that will indicate that you might want to reconsider your code. These so called code smells are, most of the time, easy to spot and almost always a guaranteed source of maintenance. Not every single smell needs to be addressed every single time you encounter it. You have to develop some kind of feeling for them. But I am sure that, after reading this post, you will at least spot more of them in your code and will start thinking. And this, my friends, is the first step of becoming a good programmer: questioning your own code.
I will not present you a full and complete list of every single smell I read about. There are zillion books, papers, articles out there who are far better than me in presenting a more complete list of smells. For now, I will stick to the most important ones. The ones I happen to encounter basically every time I write code. The ones I had the most success with after I learned to address them. The ones I see in other junior developers code often. So you will not get overwhelmed by a huge load of names, methods, principles and other stuff. But I promise to address many more problems throughout this article series.
The Problem with this problem
Every single one of us had the time when we looked at our code and thought This can be done better. I know it can! But how? You most probably were staring at a code smell.
| Inappropriate naming | Proper naming is one of the most important and most underestimated factors to consider. Every time it takes you more than a couple of seconds to remember what the class Processor, the variable int d or the method rename(String source) does you might reconsider your naming. The thinking time is a clear indicator if your naming is done well or not. The name of a class, an argument, a variable or a method can make or break the understanding of your code. |
| Long methods | A method should do exactly one thing and one thing only. If your rename(File file) method only renames your file, it has the perfect length. If your rename(File file) method, on the other hand, also calculates the new name of the file it has two purposes of existing. Calculating the new name and renaming the file. This is a clear reason to break the method into two methods. |
| Large classes | Same goes for large classes. A class should have one, and only one, reason to exist. If your class contains several hundred lines of code, juggles variables back and forth throught many methods and has different reasons to change, then you are staring at a clear sign to break up your class into smaller classes who serve only one purpose. Such god classes should definitly be avoided. |
| Long parameter lists | Methods or class constructors who take many arguments are a sign that ether your class or method does more things than just one, or you should create a class out of the arguments. A method or a class constructor which takes more than two or three arguments tends to be hard to read and to understand. |
| Duplicate Code | Duplicate code is the root of all evil. Most of the principles and best practices known to object oriented programming exist to avoid duplicate code. Every time you find yourself copy-pasting whole lines of code make sure that there is a better way to do it. |
| Many dots per line | A line of code which consists of more than one dot can and most probably is hard to understand and thus a code smell. I would try to avoid lines of code which have more than two dots. Your will save yourself a huge amount of time while debugging. |
| If-else and switch blocks | You can write every single application without a single if-else or switch block. I am not saying that they are bad and you should avoid them entirely but if you have more than one spot in your application that checks if(status == Status.Error) than you can be sure that it can be done better. |
| Comments | If you are writing an API for hundreds of thousands of people then comments are a somewhat necessary evil. But if you write code for yourself and your coworkers than comments can almost always be avoided by using proper naming. Code has to, and can be self explanatory |
In this article I am not going to show you how to avoid or solve any of the stated problems. The goal is to make you pay attention that these problems exist and to force you to think about the code you write. Recognise the smells you produce. And I am talking about the ones in your code. Being critical about your own code will make you a better programmer and let you improve yourself.