Code Craft

Reviewed by Mike Hubbartt

Why do companies pay higher salaries to experienced programmers than people just out of college but with newer skills? Experience. In time, developers learn shortcuts that streamline application development and make code easier to read by other developers that will support that application down the road. And yes, these things are important in an industry where time truly is money.

The programming classes I attended in college were focused on the specifics of the language or technique, but the tips I picked up from other programmers after leaving school made my job easier and more satisfying. I must admit I wish we had courses offered that taught some of the tips and techniques I learned from more experienced coders.

When I saw Pete Goodliffe’s Code Craft book in December, I wanted to see what he had to offer. Would it be solely aimed at new programmers, or would experienced programmers find processes and procedures that would help them in their daily tasks. I picked up a copy of the book and dug in.

Here is a list of the chapters in this book.

Book Index

Chapter 1 is the intro chapter, which goes into defensive coding rational. Is it a good idea? You bet. I don’t know how many programs have experienced unexpected bugs, but I’d guess the majority. Goodliffe suggests expecting problems is reasonable and advises a developer skip the trial-and-error approach. The techniques the author recommends for defensive coding are:

Enjoy a good coding style and sound design              Don’t code in a hurry

Trust no one                                                                Write code for clarity, not brevity

Don’t let anyone tinker with stuff they shouldn’t        Use statistical analysis tools

Compile with all warnings switched on                      Use safe data structures

Check every return value                                             Handle memory carefully

Initialize all variables during declaration                      Declare variables late as possible

Use standard language facilities                                  Cast carefully

Use a good diagnostic logging facility

Chapter 2 covers layout and presentation of source code. A new topic right? Wrong. Every company seems to have their way of entering source code, as they want to maintain consistency for other developers that may take over program support. Goodliffe’s tips on good presentation are not new – we had similar suggestions in several classes I took. My only caveat on this subject: most employers aren’t going to go along with changing source code standards, so this material is better suited for startups or people posting code for open source projects.

Chapter 3 covers naming conventions for variables, functions, types, namespaces, macros and source files. Good advice and well worth reading, but, as I mentioned about the chapter 2 materials, most companies have naming conventions and so this material is better suited for startups or people posting code for open source projects. The most important thing Goodliffe mentions in this chapter is the need for consistent usage when naming elements.

The material in chapter 3 transitions to the subject matter n chapter 4: techniques for writing self-documenting source code. I’ve come across some code that was intentionally obfuscated, or the programmer had no clear idea on to really solve the problem. Writing clear code, as well as using clear element names should reduce the amount of comments needed for source code.

Chapter 5 goes over writing code comments. I’m sure you’ve seen code with no comments, with good comments, and with the coding language itself documented. Too few and too many comments are bad, and the author advising favoring quality over quantity – something true in writing as well. And again, consistency is important.

Chapter 6 addresses error condition handling situations: when noting is reported, return values, status variables, exceptions and signals. The author also covers when and how to handle error conditions.

Chapter 7 covers software tools. Source editing tools include editors, manipulators, navigation, and revision control tools. Code construction tools include: compilers and linkers. Debugging tools include: debuggers, profilers, validators, metrics, disassemblers and fault tracking systems. Miscellaneous tools are: documentation tools and project management tools. A thorough list, but not real deep on any individual tool.

Chapter 8 goes into testing, which is an art into itself. Testing is less of a problem if do you as Goodliffe suggests: code defensively from the start, and use clear and consistent naming standards. I once worked with an Engineer that told me that, as the Test Engineer, I was responsible for any bugs in his code. Totally irresponsible and absolutely incorrect. Testing is important, but don’t count on testing to resolve lazy coding techniques.

Chapter 9 goes into the things to do when things do wrong: debugging hows and whys. Some of the problems the author mentions – segmentation faults, memory overruns, memory leaks and math errors – pop up in serious commercial software every day. We are responsible for the state of our coding, and we’d better be prepared to follow though with fixing it when our software breaks.

Chapter 10 goes into building software. Interpreted vs. compiled vs. byte-compiled languages. A programmer should know this before launching a compiler, so I’m going to skip this section. New programmers will find this interesting, but intermediate and advanced should move on to chapter 11: optimizing programs. This chapter gives reasons why and why not code should be optimized, and gives good tips how to optimize code using the compiler. But when it comes down to it, you won’t have as much need to optimize code when you write efficient code in the first place.

My overall favorite chapter in this book was Chapter 12 Insecurity Complex. This chapter istalks about code vulnerabilities and nhow to reduce them. Good stuff. Another favorite chapter was chapter 13 – how to produce good software design. Goodliffe goes into the things that demonstrate elegant coding. My complaint here was I wished he spent more space on design tools.

Chapter 14 covers software architecture: what it is, how it differs from code design, qualities of good architecture, and an overview of styles. I liked the architectural styles section the best; it covered: no architecture, layered, pipe and filter, client/server and component-based architectures. Chapter 15 was interesting but not crucial: how software grows over time – a lesson Microsoft learned well. Chapter 16 is about fostering the correct attitude and approach to programming – good to help identify coworker personality types.

Chapter 17 – 20 are familiar subjects to people working as programmers for a living. These chapters go into teamwork, source control, software specifications (excellent material) and code reviews. Again, as I said earlier, most employers aren’t going to go along with changing internal standard practices, so this material is better suited for startups or new programmers wanting to learn about these subjects before starting to work as a programmer.

Chapter 21 addresses a subject I always had issues with: timescale estimates – good chapter and worth jumping to from chapter 14 if you feel the other material isn’t useful. Chapter 22, development methodologies, is good, but is also covered in less detail than I’d like – this is one area I hope Goodliffe focuses on for a major section of a future book.

Conclusion: I like the material in this book and will look for other books by Pete Goodliffe in the future. My only negative comment is my impression that he tries to cover too much material in too little space. I’d like to see this one book written as four books, instead of four sections.

Recommendation: If you’re a Computer Science major in school, this book is worth the money. Good practical real-world tips will move you ahead of the other new graduates. If you are a hobby programmer wanting to contribute to open source coding efforts, this book explains a lot and could save you some grief from more experienced developers. Overall: a good purchase.