“If you’re developing Windows software for a commercial or shrinkwrap type market, this book should be required reading. ” —Joel Spolsky
"God help the programming industry!" —A reader from Japan
Once, TextEdit was a companion program for a book. Now, that book serves as the documentation for TextEdit. It's payback time...
I've uploaded all the chapters, adapting the formatting as best I could. Formatting and cross-references are a bit haphazard, but it's all readable. Most of the code listings are just placeholders, but you can find them all under the Source Code tab. Which is sort of the point, on GitHub...
Chapter 1 — The Road Ahead
Chapter 2 — Designing for Users
Chapter 3 — Designing for Programmers
Chapter 4 — The Mechanics of Subclassing
Chapter 5 — The Bare Bones
Chapter 6 — Exceptions
Chapter 7 — Off the Launch Pad
Chapter 8 — Child Windows
Chapter 9 — The Main Window
Chapter 10 — Customization and Persistence
Chapter 11 — Wait a Moment
Chapter 12 — File I/O
Chapter 13 — About Dialogs
Chapter 14 — File Management
Chapter 15 — Search and Replace
Chapter 16 — Printing
Chapter 17 — Changing Fonts
Chapter 18 — Going Abroad
Chapter 19 — Meanwhile, in the Background
Chapter 20 — Setup, and Down Again
Chapter 21 — The End of the Road
Appendix A — TextEdit Command Index
Appendix B — Bibliography and Recommended Reading
“Error handling has been omitted for clarity.”
Too many times have I read that sentence in a programming book or article. Not that there’s anything inherently wrong with this; simplification is a legitimate teaching device. The problem is that the literature is terribly one-sided—it’s a rare gem that says, “error handling has been included to show how it’s done.” Many programmers never learn how to handle errors and anomalies. Even more chilling, some never realize that the issue exists. The results are all around us: robustness and reliability are rarely considered defining characteristics of software.
This book gives you an understanding of what it takes to build industrial strength software—software that works reliably and robustly, software that doesn’t get between the user and his task. It will not bestow software nirvana upon you; indeed, no book ever could. That unattainable state of grace can only be approached through experience; the most a book can do is to help you get the right rather than the wrong kind of experience. My highest hope is that the book will inspire you to care—about your users, about your profession and about getting the details right.
The adjective “fragmented” describes much of the computer literature. Many books use minimalist examples to illustrate various APIs and subsystems, and rarely draw things together into a coherent whole. Again, this is not necessarily a Bad Thing; many excellent books use this approach.
Unfortunately, it is not enough. When you assemble those fragments to create a full-blown application, their interaction gives rise to an exponential increase in complexity, and a myriad of details must be considered. This aspect of software construction is rarely covered, and the litterature is left with a hole large enough to drive a truck-full of bugs through. Sadly, bugs and inconsistencies often are considered defining characteristics of computer software.
This book takes a more holistic approach; it is built around the development of a single 20,000-line application.
In addition to error handling and application architecture, the book focuses on usability. Efficient flow of information should receive much consideration during software design, but the current state of the World Wide Web is proof that it rarely receives any consideration at all. Does the user really need that animated deodorant on his desk, or would your development effort be better spent ensuring that the user can get his work done efficiently and effectively, and that his data are never lost? While I like cool stuff as well as the next programmer, I think it should be built on solid ground rather than shifting sands.