Code Quality: The Open Source Perspective and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.

Sign in to turn on 1-Click ordering.
Amazon Prime Free Trial required. Sign up when you check out. Learn More
More Buying Choices
Have one to sell? Sell yours here
Start reading Code Quality on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Code Quality: The Open Source Perspective [Paperback]

Diomidis Spinellis

List Price: CDN$ 74.99
Price: CDN$ 47.24 & FREE Shipping. Details
You Save: CDN$ 27.75 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Only 1 left in stock (more on the way).
Ships from and sold by Gift-wrap available.
Want it delivered Wednesday, September 3? Choose One-Day Shipping at checkout.


Amazon Price New from Used from
Kindle Edition CDN $32.60  
Paperback CDN $47.24  
Save Up to 90% on Textbooks
Hit the books in's Textbook Store and save up to 90% on used textbooks and 35% on new textbooks. Learn more.
Join Amazon Student in Canada

Book Description

April 3 2006 0321166078 978-0321166074 1

  • Page 26: How can I avoid off-by-one errors?
  • Page 143: Are Trojan Horse attacks for real?
  • Page 158: Where should I look when my application can't handle its workload?
  • Page 256: How can I detect memory leaks?
  • Page 309: How do I target my application to international markets?
  • Page 394: How should I name my code's identifiers?
  • Page 441: How can I find and improve the code coverage of my tests?

Diomidis Spinellis' first book, Code Reading, showed programmers how to understand and modify key functional properties of software. Code Quality focuses on non-functional properties, demonstrating how to meet such critical requirements as reliability, security, portability, and maintainability, as well as efficiency in time and space.

Spinellis draws on hundreds of examples from open source projects--such as the Apache web and application servers, the BSD Unix systems, and the HSQLDB Java database--to illustrate concepts and techniques that every professional software developer will be able to appreciate and apply immediately.

Complete files for the open source code illustrated in this book are available online at:

Customers Who Bought This Item Also Bought

Product Details

Product Description

About the Author

Diomidis Spinellis has been developing the concepts presented in this book since 1985, while also writing groundbreaking software applications and working on multimillion-line code bases. Spinellis holds an M.Eng. degree in software engineering and a Ph.D. in computer science from Imperial College London. Currently he is an associate professor in the Department of Management Science and Technology at the Athens University of Economics and Business.

Excerpt. © Reprinted by permission. All rights reserved.

In programming, as in everything else, to be in error is to be reborn.
-- Alan J. Perlis

I wish I could start this preface by writing that the book you are holding in your hands is the result of a carefully planned premeditated publishing effort that started with the title Code Reading: The Open Source Perspective and is now being completed with Code Quality. Writing so would, however, be twisting the true facts, adjusting reality to the orderly world we engineers like to see around us. The truth is that Code Quality is mostly the result of a series of fortuitous accidents.

When I signed the contract to publish Code Reading, I had in my hands the outline and a couple of completed chapters. I naively calculated the book's length and the completion schedule, based on the length and effort of the chapters I had already written. Now, if you are writing software for a living, you can probably guess that at the time the manuscript was supposed to have been finished, I had covered just slightly more than half the chapters in the outline and had already used up all the allotted pages. Looking for a respectable exit strategy, I suggested to my editor publishing the material I had completed (minus a chapter on portability) as the first volume of Code Reading and continuing the rest of the work in a second volume.We agreed, and Code Reading got published, received a number of favorable reviews, appeared in the list of the 2004 Software Development Magazine Productivity Awards, and got translated into six other languages.

In Code Reading, by using real-life examples taken out of working, open source projects, I tried to cover most code-related concepts that are likely to appear before a software developer's eyes, including programming constructs, data types, data structures, control flow, project organization, coding standards, documentation, and architectures. My plan for the second volume was to cover interfacing and applicationoriented code, including the issues of internationalization and portability, the elements of commonly used libraries and operating systems, low-level code, domain-specific and declarative languages, scripting languages, and mixed-language systems. However, with Code Reading in the hands of programmers, I now had the benefit of readership opinions. The feedback I received indicated that many were eagerly waiting for the follow-up volume, but a detailed dissection of a device driver (one of the chapters I had left for a subsequent volume) was not the material they had in mind for it. In July 2003, my then editor, Mike Hendrickson, suggested working on a book titled Secure Code Reading. Although it security is an area that interests me as a scientist, I was loath to jump into the security book bandwagon and wrote a corresponding chapter instead. With one chapter on portability and one on security, I could suddenly see the book's theme and title before my eyes. Code Quality would focus on how to read and write software code, focusing on its quality attributes, those also often described as nonfunctional properties.

The nonfunctional properties we can discern from reading a software system's code are associated with the product's nonfunctional requirements: the requirements that are not directly concerned with specific functions delivered by the system but that deal with broader emergent system properties. Some common nonfunctional properties are the various -ilities of a system: reliability, portability, usability, interoperability, adaptability, dependability, and maintainability. Two other significant nonfunctional properties concern the system's efficiency: its performance related to time constraints and its space requirements.

The skill of reading code to discern its nonfunctional properties is crucial for two important reasons. First of all, a failure to satisfy a nonfunctional requirement can be critical, even catastrophic. A system that gets some functional requirements wrong (most software products contain such errors) may well be able to operate in a degraded mode; users can be instructed to avoid using some part of the functionality. On the other hand, errors in nonfunctional properties are often showstoppers: an insecure web server or an unreliable antilock brake system (ABS) are worse than useless. In addition, nonfunctional requirements are sometimes difficult to verify.We cannot write a test case to verify a system's reliability or the absence of security vulnerabilities. Therefore, both the critical nature of nonfunctional properties and the difficulty in verifying them suggest that when dealing with nonfunctional requirements and the corresponding software properties, we need to muster all the help we can get. The ability to associate code with nonfunctional properties can be a powerful weapon in a software engineer's arsenal.

Apart from the different perspective, Code Quality follows the successful recipe of Code Reading: focus on the reading of existing code, deal exclusively with realworld examples taken out of existing open source systems, reference all examples to their source, dissect code with annotated listings, provide meaningful exercises to strengthen the reader's critical ability and skills, identify coding idioms and traps in the text's margin, summarize each chapter's advice in the form of maxims, tie practice with theory in the Further Reading section, and use the Unified Modeling Language (UML) for all diagrams. From that recipe, the most tricky ingredient was my self-imposed rule to avoid toy examples, drawing all code samples from existing open source projects. By following the rule, I often found myself spending hours to find an appropriate example: one that would illustrate the concept I was presenting, while also being understandable and short enough to include in the book. I found this exercise both intellectually simulating and a great way to impose discipline on my writing. Often, while searching for a particular weakness, I encountered other interesting elements worthy of discussion. At other times, my search for an example of a theoretical concept proved fruitless: In those cases, I could then credibly reason that the concept was not important enough in practice to include in the text.

The rationale and motivation behind Code Quality are also the same as those that started Code Reading: The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or formally used as a method for learning how to design and program. The popularity of open source software has provided us with a large body of code that we can all freely read and learn from. A primer and reader, based on open source software, can be a valuable tool for improving one's programming abilities. I therefore hope that the existence of the two books will spur interest to include code-reading courses, activities, and exercises in the computing education curriculum so that in a few years, our students will learn from existing open source systems, just as their peers studying a language learn from the great literature.

Content and Supplementary Material

I decided to base the source code examples for Code Quality on the same systems and distributions as those I used in Code Reading. I reasoned that it was important to provide continuity between the two volumes, allowing the reader to see how the same source code can be read to discern the functional, architectural, and design characteristics covered in Code Reading and the nonfunctional characteristics covered in Code Quality.

The code used in this book comes from code snapshots that are now mostly only of historic value. This has, however, provided me with the opportunity to show real security vulnerabilities, synchronization problems, portability issues, misused api calls, and other bugs that were identified and fixed in more recent versions. The code base's age makes it likely that its authors by now either have advanced to management positions where reading books as this one is frowned upon or have an eyesight unable to deal with this book's fonts. These changes conveniently provide me with a free license to criticize code without fear of nasty retributions. Nevertheless, I understand that I can be accused of disparaging code that was contributed by its authors in good faith to further the open source movement and to be improved upon rather than bemerely criticized. I sincerely apologize in advance if my comments cause any offense to a source code author. In defense, I argue that in most cases, the comments do not target the particular code excerpt but rather use it to illustrate a practice that should be avoided. Often the code I am using as a counterexample is a sitting duck, as it was written at a time when technological and other restrictions justified the particular coding practice, or the particular practice is criticized out of the context. In any case, I hope that the comments will be received good-humoredly and openly admit that my own code contains similar, and probably worse, misdeeds.

I chose all the systems used in the book's examples for practical reasons having to do with the suitability of the code as an instructional vehicle. Things I looked for were code quality, structure, design, utility, popularity, and a license thatwould not makemy publisher nervous. I strived to balance the selection of languages, actively looking for suitable Java and C++ code. However, where similar concepts could be demonstrated using different languages, I chose to use C as the least common denominator. Thus, 61% of the code references in the book are to C code; these include examples related to programming in the small (applicable to any language) and systems programming (which is done mostly in C). Another 19% of the examples refer to Java code. I chose to use Java code to demonstrate elements associated with object-oriented concepts and the corresponding apis. Most of these concepts also apply verbatim to C# and many apply to C++ (which is referenced in 4% of the examples).

I've also put more emphasis on Unix apis and tools than on the corresponding Windows elements. My reasoning here also involved the logic of the least common denominator: Many of the Unix tools and apis are also available under Windows, whereas the reverse is not true. Also, a number of Unix-compatible systems, such as gnu/Linux and the bsd variants, are freely available, often in the form of a bootable live cd-rom, so that anyone can easily experiment with such a system. Finally, the Unix apis and tools, at the level of detail I use in my examples, have remained remarkably stable over the past 30 years, providing us with an excellent base for discussing and illustrating general principles. Nevertheless, in a number of places, I reference Windows apis and commands to discuss how things work on a different platform. Don't let those references fool you: I don't pretend that this book's coverage of the Windows platform programming issues is complete or even comprehensive, any more than I claim the same for the Unix systems.

Apart from the use of open source software for all its examples, this book might be accused of (narrowly) missing a number of popular bandwagons, including Java, C#, Windows, Linux, and a writing style oriented toward solving today's itch now. I value all of the preceding: 29% of the machines under my roof run Linux, I teach a Java programming course, I've written a number of programs for the Windows platform, and my bookshelf has at least ten books filled with sequentially numbered paragraphs offering concrete, problem-solving advice. However, I also believe that in today's changing world, it is important to understand the principles behind the homily. As you will see in the following chapters, once we focus on the principles

  • The choice of the underlying technology is often immaterial
  • What we learn has a wider applicability and a longer lifespan
  • The concrete advice comes on its own (look at the list of "advice to take home" at the end of each chapter)

Most important, the understanding of the principles behind our craft is what distinguishes an expendable coder from a valued software engineer.

Customer Reviews

There are no customer reviews yet on
5 star
4 star
3 star
2 star
1 star
Most Helpful Customer Reviews on (beta) 4.0 out of 5 stars  4 reviews
14 of 14 people found the following review helpful
4.0 out of 5 stars Spinellis: The Anti-Kernighan Oct. 1 2006
By alkmaar - Published on
First of all, this author is a serious academic. The book is worth reading and probably will be for a long time to come. It's also a fine production typesetting-wise. The previous review's complain about copy-editing errors in the book is really missing the point, because those could be easily overlooked when you read books of such a grand scale.

The good points aside, however, I'm honestly a little surprised that there was only one review prior to the current one. This seems to indicate it's neither that popular, nor that obviously destined to be a classic, as the author probably had in mind when he was composing it.

One drawback, which it shares with its older sister, "Code Reading" (2003), is a pompous writing style. Lots of words and pages are wasted dwelling on the obvious, and in quite a few spots the way too obvious. Just go through one of those end-of-a-chapter points to take home, you'll know what I mean. As couple of more specific examples, take a look at the gratuitous explanation on omitting the constant factor of the big O notations on p.177; the needless yet painstaking attempt at explaining and justifying usages of charts in log scale on p.13.

This is in sharp contrast to the legendary writing of Brian Kernighan, whose "The Practice of Programming" (1999), "The C Programming Language" (1988), and "The UNIX Programming Environment" (1984) are all greats in professional computing, short, sweet, yet with densely packed knowledge content. They are truly time-tested classics, deserving read, and reread.
5 of 5 people found the following review helpful
4.0 out of 5 stars Important information, but it's not an easy read... Oct. 16 2006
By Thomas Duff - Published on
Code Quality by Diomidis Spinellis is the follow-up volume to Code Reading. Like the first one, there's a lot of wisdom in the writing, but the Unix/C++ and computer majors will get the most out of it.

Contents: Introduction; Reliability; Security; Time Performance; Space Performance; Portability; Maintainability; Floating-Point Arithmetic; Source Code Credits; Bibliography; Index; Author Index

Spinellis uses examples from open source code and software to discuss what makes for quality code. In most cases, the examples are designed to show what's *not* good. This might include buffer overruns, algorithms that don't scale well, and other various and sundry items. Each chapter ends with an Advice To Take Home section, which recaps all the suggestions and practices in a series of one to two line summaries (with references back to the detailed discussion). Because each chapter pretty much stands alone, you can focus on areas that make the most sense to you in your particular area of interest.

While I'd like to recommend the book without reservations, I feel that certain types of programmers will get more out of it than others. A large number of the examples are based on Unix/C++/Assembler code. In those situations, you will likely understand the concept being discussed, but the details may not be as clear. Also, Spinellis' background as a university professor seeps through, as some of the discussions are best reserved for math or computer science majors.

Is it worth reading? Yes. Just be prepared to work at it...
9 of 11 people found the following review helpful
3.0 out of 5 stars Good book, marred by copy editing errors June 27 2006
By Pen name - Published on
This book has a great deal of interesting and practical advice. A few people learn much of this advice through years of experience, but from what I have seen, most do not. This book would be most useful to beginning and intermediate software developers who have not yet discovered the wisdom by trial and error, or experienced developers who want to communicate the information to less knowledgable colleagues in an easily digestible format.
Unfortunately, I was disappointed by by the quality of copy editing. I would have given the book 4 stars otherwise. However, I would still recommend the book, even with the errors, because it's worth it.
I wrote an email to the author, using the email address given on his website, giving in detail the errors I found in the book (First Printing, March 2006).
The author kindly emailed me promptly to inform me that he had added to the errata page the errors I had identified. Thanks to the author for the prompt reply and action.
I hope that A-W and other publishers will do a better job with their proofreading quality, like they used to a few years ago.
2 of 2 people found the following review helpful
5.0 out of 5 stars Refreshingly Complete and Precise July 20 2009
By Leon Matthews - Published on
The book is full of hard-won experience cast nicely into prose. It's a very worthwhile read. The author doesn't shy away from explaining difficult or intricate concepts, where necessary, and each point is illustrated with example code from real systems.

For example, the chapter on Maintainability opens with four attributes of a maintainable system (from ISO/IEC 9126-1:2001) that really struck a chord with me.

Analysability: Finding the location of an error or the part of the software that must be analysed
Changeability: Implementing the maintenance change on the system's code
Stability: Not breaking anything through the change
Testability: Validating the software after the change

I know maintainable code when I see it -- it has a certain feel... Up until now though I've often struggled to express that feeling to non-programmers, or perhaps more importantly, to less experienced colleagues.

Highly recommended.

Look for similar items by category