878 A SENSE OF STYLE $26.1 As noted in an earlier chapter (in the more general context of design principles),The comment was in many of the style rules were originally developed for libraries,and then found their way the introduction to into ordinary software development.In object technology,of course,all software is chapter 23. developed under the assumption that even if it is not reusable yet it might eventually be made reusable,so it is natural to apply the same style rules right from the start. Self-practice Like the design rules of the preceding chapters,the style rules which follow have been carefully applied to the many examples of this book.The reasons are obvious:one should practice what one preaches;and,more fundamentally,the rules do support clarity of thought and expression,which can only be good for a detailed presentation of the object- oriented method. The only exceptions are a few occasional departures from the rules on software text layout.These rules do not hesitate to spread texts over many lines,for example by requiring that every assertion clause have its own label.Lines are not a scarce resource on computer screens;it has been observed that with the computer age we are reversing the direction of the next-to-last revolution in written communication,the switch from papyrus rolls to page-structured books.But this text is definitely a book,structured into pages,and a constant application of the layout-related rules would have made it even bigger than it is. The cases of self-dispensation affect only two or three layout-related rules,and will be noted in their presentation below.Any exception only occurs after the first few examples of a construct in the book have applied the rules scrupulously. Such exceptions are only justified for a paper presentation.Actual software texts should apply the rules literally. Discipline and creativity It would be a mistake to protest against the rules of this chapter(and others)on the grounds that they limit developer creativity.A consistent style favors rather than hampers creativity by channeling it to where it matters.A large part of the effort of producing software is spent reading existing software and making others read what is being written. Individual vagaries benefit no one;common conventions help everyone Some of the software engineering literature of the nineteen-seventies propounded Sentence initalics the idea of "egoless programming":developing software so that it does not reflect from D.H.Brandon, “Data Processing anything of its authors'personality,thereby making developers interchangeable.Applied Organiation and to system design,this goal is clearly undesirable,even if some managers may sometimes Manpower Planning", long for it(as in this extract of a programming management book quoted by Barry Boehm: Petrocelh,1974, "...the programmer('s]creative instincts should be totally dulled to insure uniform and emphasis in original Ouoted in Boehm understandable programming",to which Boehm comments:"Given what we know about 1981,p.674. programmers and their growth motivation,such advice is a clear recipe for disaster"). What quality software requires is egoful design with egoless expression.878 A SENSE OF STYLE §26.1 As noted in an earlier chapter (in the more general context of design principles), many of the style rules were originally developed for libraries, and then found their way into ordinary software development. In object technology, of course, all software is developed under the assumption that even if it is not reusable yet it might eventually be made reusable, so it is natural to apply the same style rules right from the start. Self-practice Like the design rules of the preceding chapters, the style rules which follow have been carefully applied to the many examples of this book. The reasons are obvious: one should practice what one preaches; and, more fundamentally, the rules do support clarity of thought and expression, which can only be good for a detailed presentation of the object￾oriented method. The only exceptions are a few occasional departures from the rules on software text layout. These rules do not hesitate to spread texts over many lines, for example by requiring that every assertion clause have its own label. Lines are not a scarce resource on computer screens; it has been observed that with the computer age we are reversing the direction of the next-to-last revolution in written communication, the switch from papyrus rolls to page-structured books. But this text is definitely a book, structured into pages, and a constant application of the layout-related rules would have made it even bigger than it is. The cases of self-dispensation affect only two or three layout-related rules, and will be noted in their presentation below. Any exception only occurs after the first few examples of a construct in the book have applied the rules scrupulously. Such exceptions are only justified for a paper presentation. Actual software texts should apply the rules literally. Discipline and creativity It would be a mistake to protest against the rules of this chapter (and others) on the grounds that they limit developer creativity. A consistent style favors rather than hampers creativity by channeling it to where it matters. A large part of the effort of producing software is spent reading existing software and making others read what is being written. Individual vagaries benefit no one; common conventions help everyone. Some of the software engineering literature of the nineteen-seventies propounded the idea of “egoless programming”: developing software so that it does not reflect anything of its authors’ personality, thereby making developers interchangeable. Applied to system design, this goal is clearly undesirable, even if some managers may sometimes long for it (as in this extract of a programming management book quoted by Barry Boehm: “…the programmer[‘s] creative instincts should be totally dulled to insure uniform and understandable programming”, to which Boehm comments: “Given what we know about programmers and their growth motivation, such advice is a clear recipe for disaster”). What quality software requires is egoful design with egoless expression. The comment was in the introduction to chapter 23. Sentence in italics from D.H. Brandon, “Data Processing Organization and Manpower Planning”, Petrocelli, 1974, emphasis in original. Quoted in [Boehm 1981], p. 674