So, we meet again with what makes code stink. As I mentioned in my blog last week, this is a continuation from the same post that I covered last week, as there were simply too many points I wanted to hit upon to fit in one post. For those who missed last week’s post or can’t remember, smelly code is basically trends in code that commonly known to cause problems. The goal is to make sure you code doesn’t stink when you are done with it, or you’ll regret it later down the line.
The next item on the list are comments. Comments can be great. They provide insight into how the developer was thinking, why they designed it the way they did, what is going on in that quadruple nested for-loop below the comment, etc. The thing is, if you are really a good developer, an argument can be made that the code can speak/explain itself. Personally, I’ve always found comments useful and insightful, but the point here is that your code should not be so ambiguous or so complicated that you need an entire paragraph just to explain what is going on. While I don’t necessary agree that there should be no comments at all, I do agree that comments should be kept to a minimum, and if you can’t, something is wrong with your code.
Pressing further down Jeff Atwood’s list of smelly code we run into the category of duplicate code. Please don’t duplicate your code. The reasons are self-explanatory, but I will reiterate: it is bad, wasteful, and inefficient. If you need to perform a task more than once, put it in a function, simple as that. You’ll save everyone a few headaches. Similarly, he mentions dead code. That is code that is sitting in there, wasting its life away as a comment or performing some task is never used, wasting resources. There should never be a need to leave unused code. The wonderful invention of version eliminated the need to leave old code sitting in a program.
The last item on his list that I want to touch upon is the bad habit of making items public when shouldn’t be, or as he calls it, indecent exposure. There should be a strong effort to make everything is as private as possible, and there should be a damn good reason if it not private. Exposing the internals of a class is dangerous and unwarranted. Unless something absolutely has to be public, it should stay private.
There were items on Atwood’s list that I felt were unnecessary or didn’t completely agree with, but overall, I found his list of code warning signs useful and brought up many valid points. As developers we want our code to be clean, efficient, and easy to read. I feel that going through this list would certainly help anyone reach that goal. A lot of the items on the list are thing experienced developers should know better than to try anyhow, but it can’t hurt double check when you are done. I know I certainly will try to run through his list in the future.
Link:
https://blog.codinghorror.com/code-smells/
From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.