So I’ve been switching back and forth between two non-fiction tomes lately: Clean Code and Code Leader. Code Leader I’m liking, but Clean Code I’m loving (so far). I think it appeals to my OCD nature.
For some time now I’ve enjoyed spending a fair amount of my time working on the quality of the code I write, through refactoring and focusing on code cleanliness and readability (CodeRush Xpress for .NET or Castalia for Delphi make this both fun and easy). Clean Code is, thus far, full of some very well thought out "truthiness" about writing quality code, such as applying "The Boy Scout Rule" when writing code: Leave the campground cleaner than you found it.
It also includes many rules of thumb to use when programming to keep your code clean and readable, such as:
- Blocks of code nested more than one level deep are a sure indication of needing an extract-method refactoring
- Method calls are chance to make your code more readable and self documenting by using meaningful method names
- Code within a block should be one line – probably a method call (this implies that you should not see nested blocks deeper than one or two levels)
- Methods should do one thing only
- Comments are not an inherently good thing – whenever you are prepared to write a comment, instead try to see if the code could be improved so that a comment is not needed
- Methods should have none, one, or maybe two parameters – three or more is pushing it, and avoid output parameters
I don’t want to devalue the book so I’ll cut myself short (though I’d love to go on, and trust me there’s much more).
I’m sure those who have read the book will be quick to point out these are but a handful of the nuggets found in the first third of the book. I’ll admit I’m just beginning to scratch the surface of this book and, from what I’ve read, the book gets very difficult to digest half way through. However, I’m loving what I’ve read so far.
These two books are my first go at reading some of the more theoretical and philosophical thoughts when it comes to software development and, so far, I’m liking it a lot. It’s a nice change from hands-on C# or TSQL.
Update: I was reading through a friend’s blog (Jacob Thurman, author of the great Castalia IDE expert for Delphi) and found a post on a related topic: giving members descriptive names. His post has some great insight, but also links to a blog post by Robert Nystrom which contains many guidelines to keep in mind when naming members in source code.