I started reading “Clean Code” by Robert C. Martin (aka Uncle Bob) and wanted to share my thoughts on Chapter 1, aptly named “Clean Code.”
Uncle Bob starts out showing what bad code is and what good code is. I won’t go much into bad code in this post other than a brief example below, and say that it causes so much technical debt where it can (and has) brought some companies down. Good code on, the other hand, is a pleasure to work on and allows a programmer to “go fast”—by fast, I mean one will be able to tackle a requirement/need confidently, efficiently, and cleanly as much as possible.
Bad code:
public double addSalesTax(double i, double j) {
return i + (i * j);
}
Good code:
public double addSalesTax(double purchaseAmount, double taxRate) {
return purchaseAmount + (purchaseAmount * taxRate);
}
As you can see the bad code isn’t easily understood, while the good code is straightforward—and the only refactoring done was making the signature arguments and variable names more meaningful! To elaborate a bit more on good—or clean—code, let me recall comments from the the “OG” (Original Gangster) programmers on what it means to them.
Bjarne Stroustrup said: “I like my code to be elegant and efficient.” and “Clean code does one thing well.”
Grady Booch further enhanced it by saying: “Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.”
And, finally, Ward Cunninghum commented: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”
The unifying idea or trait that I find in their comments is a good software craftsman cares about his/her craft. That is, when one cares about something, he/she will naturally put in his/her best effort to ensure that the highest quality is attained. Take, for example, building furniture…you plan things out first; you take precise measurements; you build each piece with a single purpose, like a leg of a table; and you try your best to put them together as cleanly and effectively as possible.
These concepts, as you might have already figured, are pretty much how it is, too, with building software. You lay out the classes necessary using tools like using UML; you write modular code; you use best practices, such as meaningful naming conventions; you write unit and acceptance tests to ensure code quality; you do integration testing to make sure it works well with other components, and so on and so forth.
Writing clean code then is a no-brainer and just makes sense. It is a must if you want to be a great programmer—and who doesn’t want to be one? So with that in mind, here are some practical steps, that grabbed my attention, on how one can achieve what I call “clean codeliness”:
- While coding, make continuous improvements, even if small, as it will make the code clean over time.
- Keep learning, and from many credible sources at that (i.e. read various sites/blogs on a particular subject).
- Work to gain “code-sense” skills, which is the skill where given some code a programmer can make something out of it, while others will not have a clue what to do or where to start.
- Learn principles and techniques, such as the S.O.L.I.D. principles.
- Finally, practice, practice, practice.
So, here’s the bottom line: The main trait you will only need to become a great programmer is caring. Because if you care deeply enough about your craft—and coupled with the right amount of effort and planning—everything else will follow.