Recently I read the book Clean Code
Every chapter goes on specific part of programming, amongst others: using meaning full names, how to write good, consise and easy-to-understand functions, writing good comments, writing good unit tests, and having a good class design. A lot of content I already knew or was at least aware of, either intuitively through experience or from other sources. However, that didn’t made reading it any less usuful, the book does very well on explaining why and offering good arguments, just to convince other people. The book also questions a lot of common practices, I did not think of before.
I’ll pick some chapters to explain more in detail the content. First chapter goes into importance of good naming. Amongst others, variable should have meaning full names, and one letter variables like j or h should be used only for simple loop iteration. Class names should correspond to domain words like Customer, WikiPage or AddressParser. Postfixes like Info (AccountInfo) or prefixes like I (ICustomer) just clutter up and don’t add anything. Same goes for prefixed variable names like m_dsc or int_ordernum. Function names should be verbs like addAccount or deletePage.
Another chapter goes on a often mis-understood or underestimated subject: writing good comments. One point the auther made is to limit the amount of generated comments. IDE-generated comments containing lots of @param, @return tags, etc., just clutter up your code while not adding information: if you use clear names, you don’t need to explain each parameter. Worse, they increase the change that of introducing ‘lies’: comments that do not corrrespond with the code the’re commenting.
Allthough the title of the book suggests it’s about programming in general, the book is slightly targeted to Java-programming. All code-samples are Java code, and some times the book refers to Java standards (like the Bean standard). C# developers could benefit from the book as well, as well as developers in similar languages, allthough some code samples could be harder to understand. Programmers in languages like Haskell, XSLT, Lisp would benifit less of the book.
I could go on, but I’d just recommend you to read the book if you’re a programmer yourself or have to manage programmers directly!
