$26.1 COSMETICS MATTERS! 877 significant system or subsystem.If you express a basic algorithm-at the level of Quicksort,say,or Euclid's algorithm-in C and in the notation of this book,expect the O-O version to be at least as large.In many cases,if you apply the principles thoroughly, it will be larger,since it will include assertions and more type information.Yet in ISE's experience of looking at medium-scale systems we have sometimes found(without being able to give a general law,as the circumstances vary considerably)the object-oriented solution to be several times smaller.Why?This is not due to terseness at the "micro"level but to systemwide application of the architectural techniques of the O-O method: Genericity is one of the key factors.We have found C programs that repeated essentially the same C code many times to handle different types.With a generic class-or for that matter a generic Ada package-you immediately get rid of that redundancy.It is disturbing in this respect to see that Java,a recent O-O language based on C,does not support genericity. Inheritance is also fundamental in gathering commonalities and removing duplications Dynamic binding replaces many complex decision structures by much shorter calls Assertions and the associated idea of Design by Contract avoid redundant error checking,a principal source of bloat. The exception mechanism gets rid of some error code. If you are concerned with source size,make sure to concentrate on these architectural aspects.You should also be terse in expressing algorithms,but never skimp on keystrokes at the expense of clarity The role of convention Most rules define a single permissible form,with no variants.The few exceptions include font use,which is governed by external considerations(what looks good in a book may not be visible on overhead transparencies),and semicolons,for which there exist two opposite schools with equally forceful arguments(although we will have a few universal rules anyway).In all other cases,in line with the introductory methodology chapter's exhortations against wishy-washiness,the rules leave about as much room to doubt as a past due reminder from the Internal Revenue Service. The rules are rooted in a careful analysis of what works and what works less well, resulting from many years of observation;some of the rationale will appear in the discussion.Even so,some rules may appear arbitrary at first,and indeed in a few cases the decision is a matter of taste,so that reasonable persons working from the same assumptions may disagree.If you object to one of the recommended conventions,you should define your own,provided you explain it in detail and document it explicitly;but do think carefully before making such a decision,so obvious are the advantages of abiding by a universal set of rules that have been systematically applied to thousands of classes over more than ten years,and that many people know and understand.§26.1 COSMETICS MATTERS! 877 significant system or subsystem. If you express a basic algorithm — at the level of Quicksort, say, or Euclid’s algorithm — in C and in the notation of this book, expect the O-O version to be at least as large. In many cases, if you apply the principles thoroughly, it will be larger, since it will include assertions and more type information. Yet in ISE’s experience of looking at medium-scale systems we have sometimes found (without being able to give a general law, as the circumstances vary considerably) the object-oriented solution to be several times smaller. Why? This is not due to terseness at the “micro” level but to systemwide application of the architectural techniques of the O-O method: • Genericity is one of the key factors. We have found C programs that repeated essentially the same C code many times to handle different types. With a generic class — or for that matter a generic Ada package — you immediately get rid of that redundancy. It is disturbing in this respect to see that Java, a recent O-O language based on C, does not support genericity. • Inheritance is also fundamental in gathering commonalities and removing duplications. • Dynamic binding replaces many complex decision structures by much shorter calls. • Assertions and the associated idea of Design by Contract avoid redundant error checking, a principal source of bloat. • The exception mechanism gets rid of some error code. If you are concerned with source size, make sure to concentrate on these architectural aspects. You should also be terse in expressing algorithms, but never skimp on keystrokes at the expense of clarity. The role of convention Most rules define a single permissible form, with no variants. The few exceptions include font use, which is governed by external considerations (what looks good in a book may not be visible on overhead transparencies), and semicolons, for which there exist two opposite schools with equally forceful arguments (although we will have a few universal rules anyway). In all other cases, in line with the introductory methodology chapter’s exhortations against wishy-washiness, the rules leave about as much room to doubt as a past due reminder from the Internal Revenue Service. The rules are rooted in a careful analysis of what works and what works less well, resulting from many years of observation; some of the rationale will appear in the discussion. Even so, some rules may appear arbitrary at first, and indeed in a few cases the decision is a matter of taste, so that reasonable persons working from the same assumptions may disagree. If you object to one of the recommended conventions, you should define your own, provided you explain it in detail and document it explicitly; but do think carefully before making such a decision, so obvious are the advantages of abiding by a universal set of rules that have been systematically applied to thousands of classes over more than ten years, and that many people know and understand