Greetings! Long time no blogging!
The usual excuses apply: no time, too much work, to tired to think about anything but work…
This post will hopefully make my readers smile, as I am going to list my favorite bits of advice on programming I have taken from “The Elements of C# Style” by K.Baldwin, A.Gray and T. Misfeldt. This book makes for a short and wonderful read, and in my opinion should be re-read on regular basis by all practitioners. It covers naming, design, documentation, the programming language and packaging and release. The book is full or “do’s” and “don’ts”, and it is the “don’ts” that I smile at because, admittedly, I have done all of them at some point in the past…
Here are ten, in the “smiley” order:
- Do It Right the First Time: the authors advice to apply this rule to any code one writes, not just what is designed for production. Probably the best advice I have ever come across, and the one I seldom practice. Quite often I would begin by simply trying a few things out, getting the code to work and then never coming back to clean it up and make it presentable.
- Adhere to the Principle of Least Astonishment: this advice is one of my favorite! The authors write that simplicity and clarity must be preferred over complexity and unpredictability.
- Keep Your Comments and Code Synchronized: this one is followed by a quote by Norm Schryer: “When the code and the comments disagree, both are probably wrong.”
- Recognize the Cost of Reuse: reuse is often held up as the holy grail, however, truly re-usable code is difficult and time consuming. In addition, it increases code dependency and, sometimes, complexity.
- Separate Distinct Programming Layers: as this creates a flexible and maintainable architecture. Personally, I should be remembering this one more often…
- Reuse Objects to Avoid Reallocation: this piece of advice is from the efficiency chapter. The idea is to cache and reuse frequently created objects with limited lifespan. Use accessor methods (get) rather than constructors.
- Avoid the Use of End-line Comments: according to the authors these interfere with the overall structure of the code. One-line comments should be placed on separate line. I agree, will remember this one in the future.
- Do Not Use try…throw…catch to Manage Control Flow: one should use exceptions handling mechanism to handle exceptional conditions. Except for serious failures there should be a way to continue execution (and notifying the users or logging errors).
- Organize Source Code into Regions: this one really aids in improving readability and I often forget it!
- Consider Using Code-checking Software to Enforce Coding Standards: it is true that tools like FxCop are very useful and one can learn more about the language by simply following its suggestions! However, sometimes I turn FxCop off because I find that I don’t like to see most of my code highlighted in red!
So, how many times did you smile?
codefying 