One of the biggest conundrums for the technical writer is how to handle source code in a book. The goal is to present an easily understood example to the reader—one that demonstrates a principle in a clear and concise manner. In fact, complexity is a problem with many examples—the author tries to stuff too much information into the example and ends up obfuscating the very principles that the reader is supposed to obtain. So, very often simplicity must win the day in creating application source code for a book, despite the desire of the author to present something more real world, something with additional glitz and polish.
Because the goal of an example is to teach, very often the examples you see in a book have more comments than those that you see in real life. An example in a book must include as much information as possible if the code is going to fulfill its purpose. Of course, book comments should illustrate all the best principles of creating comments in real code. In short, if real world code looked a bit more like book code, then its possible that developers would spend far less time trying to figure code out and more time making changes.
Some readers will take the author to task because the code may not always provide the error trapping that production code provides. In fact, as with many teaching environments, the safety features in code are often removed for the sake of clarity. This problem plagues other environments too. All of my woodworking magazines post a note near the beginning of the magazine telling the reader that the safety devices have been removed for the sake of clarity and that no one in their right mind would actually work with woodworking equipment without the safety devices. Likewise, the code you see in a book often lacks good error trapping, making the principle that the code demonstrates clearer, at the cost of fragility. You can usually cause book examples to break easily, but no one in their right mind would create production code like that.
The feature that I’ve constantly worked on with the code in my books is accessibility. In as much as possible, the code demonstrates how to make an application usable by those with special needs. Of course, as with the exception handling, it isn’t always possible to add all of the required accessibility features without making the code less clear. Still, I’m a strong advocate of making code completely accessible whenever possible.
Readers will likely question just how useful book code is if it leaves safety and accessibility features out. Remember that the goal is to teach. Let me know your thoughts about source code in books at John@JohnMuellerBooks.com.