Principled Programming
Principled Programming
developer.*
A Web Magazine for Software Developers
Principled Programming
By Daniel Read Authors note: This was the first essay about software development that I ever wrote, which was sometime in early 2001. I enjoyed writing it so much, that I decided to start the developer.* web site so that I could have a place to publish other writings. During the first two years of the sites existence, Principled Programming was by far the most popular article. I had intentions at one time to expand to a list of about thirty principles, with the idea of collecting them into a book eventually. I still may do that someday. Looking back at these principles now, two years after writing them, Im mostly happy with what I read. While I'm resisting the urge to do some re-writing on this one, I still agree 100% with the principles as stated, and hope that youll get something out of them.
DeveloperDotStar.com
Page 1 of 9
developer.*
One aspect of programming in general we too often neglect is that of aesthetics. Aesthetics is about beauty and elegance, and the appreciation of these qualities. Many people, however, believe that aesthetics is only important when talking about art and literature. Too few people realize the importance of beauty and elegance in everyday things, and too few developers realize the importance of these in the writing of code. Aesthetics is especially important in software development, a realm where we are constantly dealing in layers of abstractions. The aesthetic aspects of our abstractions are directly related to their understandability, and therefore their usefulness. A developer should strive for beauty, no matter what tool or language he or she is using. Beauty can be achieved on many levels, from the high level of the overall elegance of a system design to the lowest level of the visual appearance of code on the screen. Neatness counts. The best code not only works efficiently and correctly, and is well formed from the compiler's point of view, but the best code is also visually pleasing to the human eyeand therefore easier for the human brain to absorb and understand. Steve McConnell writes in Code Complete, "The visual and intellectual enjoyment of wellformatted code is a pleasure that few nonprogrammers can appreciate. But programmers who take pride in their work derive great artistic satisfaction from polishing the visual structure of their code." (Page 399) The Principle of Aesthetics states: Strive for beauty and elegance in every aspect of your work.
DeveloperDotStar.com
Page 2 of 9
developer.*
come. As for our employers or benefactors, we short-change them by delivering less value; if poor enough, our code may even become a liability to the company. Leaving our fellow developers in this situation is discourteous to say the least, but leaving our employers in this situation is much worse: we make an agreement to produce quality code for a price. Our employers have paid us for out work, but how did they fare in the bargain? The Principle of Clarity States: Value clarity equally with correctness. Utilize the proven techniques that will produce clarity in your code. Correctness will likely follow suit.
DeveloperDotStar.com
Page 3 of 9
developer.*
DeveloperDotStar.com
Page 4 of 9
developer.*
The key to avoiding potholes is to be explicit. Trouble lurks in the implicitin the undocumented and untested assumption, in the arcane technique, and in the undocumented intent of the developer, which gets lost forever like a ship sinking silently in a vast, opaque ocean. The Principle of Explicitness States: Always favor the explicit over the implicit.
DeveloperDotStar.com
Page 5 of 9
developer.*
DeveloperDotStar.com
Page 6 of 9
developer.*
assumptions any given routine makes, and its relationship with other routines and shared data, which decreases the incidence of bugs. The testing of assumptions is one of the cornerstones of defensive programming. Every piece of code contains assumptions. Some assumptions are fairly safe and don't need testing or documenting. (That said, our error handling scheme should always be there to gracefully catch when our untested assumptions do indeed fail.) However, we can and should test for (and document) the many other assumptions that are less obvious. The most common kind of assumptions that should be tested (and thereby documented), are the prerequisites that a given routine relies upon. These tests usually take the form of a series of IfThen statements at the top of the routine. If any of the tests fail, then your code might either take corrective action, or perhaps raise a specific error message explaining that an assumption failed. (Another often overlooked method for testing assumptions is the use of assertions, which are True/False expressions that are usually only compiled into debug versions of the program for testing.) The Principle of Assumptions states: Take reasonable steps to test, document, and otherwise draw attention to the assumptions made in every module and routine.
DeveloperDotStar.com
Page 7 of 9
developer.*
lives. However, as developers, we are in a position to help solve this problemone application at a time. As software developers, our primary responsibility for user interaction lies in user interface design. Let's face it: in most cases there is not a detailed user interface design prepared in advance. Most user interface design decisions (and this includes report design) are made by the developer at the time of construction. Therefore, in most cases, it is solely the job of the developer to take steps to make sure the user is never made to feel stupid. The developer writes the error messages and prompts. The developer places the buttons and fields on the form. The developer, therefore, has almost total control over the users experience. The Principle of User Interaction states: Never make the user feel stupid.
DeveloperDotStar.com
Page 8 of 9
developer.*
character. The Principle of Other People's Time and Money is a less friendly way of saying the same thing. Take pride in your work, because your work is you, and other people will judge you based on your worksometimes solely on your work. Even if you don't care about being judged, do you care about doing the right thing? Do you care about feeling good about taking money for writing that code? Do you care about how you and your work reflects on the profession of software engineering as a whole? Writing code for hire is not a game for our own amusement, and the quality of each developers work reflects on all other developers. The Principle of Other People's Time and Money states: A true professional does not waste the time and money of other people by delivering poor quality work. ### Daniel Read is editor and publisher of the developer.* web magazine. He lives in Atlanta, GA, where he works as a software architect. He is currently at work on a book about software development crafted for a business audience.
DeveloperDotStar.com
Page 9 of 9