668 ON METHODOLOGY $19.2 Advisory Rules methodology principle In devising advisory rules (positive or negative),use principles,not platitudes. To help make the distinction,examine the rules'negation. Here is an example of advisory negative,extracted from the discussion of type conversions (casts)in the C++reference book: Explicit type conversion is best avoided.Using a cast suppresses the type checking From [Ellis 19901. provided by the compiler and will therefore lead to surprises unless the programmer really was right. This is accompanied by no explanation of how the programmer can find out whether he "really was right".So the reader is introduced to a certain language mechanism(type casts),warned,rightly,that it is dangerous and will"lead to surprises";advised implicitly that the mechanism may sometimes be needed;but given no clue as to how to spot the legitimate uses. Such advice is essentially useless;more precisely,it has a negative effect- impressing on the reader that the tool being described,in this case a programming language,is marred by areas of insecurity and uncertainty,and should not be trusted at all. Exceptions Many rules have exceptions.But if you present a software methodology rule and wish to indicate that it may not always apply,you should say precisely what cases justify exceptions.Otherwise the rule will be ineffective:each time a developer runs into a delicate case(that is to say,each time he truly needs your advice),he will be entitled to think that the rule does not apply. Consider the following paragraph from an article about software methodology, coming after the presentation of a rather strict set of rules: The strict version of the class form of the Law of Demeter is intended to be a From guideline,not an absolute restriction.The minimization version of the law's [Lieberherr 1989]. class form gives you a choice of how strongly you want to follow the strict version of the law:the more nonpreferred acquaintance classes you use,the less strongly you adhere to the strict version.In some situations,the cost of obeying the strict version may be greater than the benefits. It is difficult,after reading this extract,to decide how serious the authors are about their own rule;when should you apply it,and when is it OK to violate it? What is wrong in not the presence of exceptions in a general guideline.Because software design is a complex task,it is sometimes inevitable (although always undesirable)to add to an absolute positive"Alays do X in situation 4"or an absolute negative"Never do Y in situation A"the qualification"except in cases B.Cand D".Such a qualified rule remains an absolute positive or negative:simply,its domain of application668 ON METHODOLOGY §19.2 Here is an example of advisory negative, extracted from the discussion of type conversions (casts) in the C++ reference book: Explicit type conversion is best avoided. Using a cast suppresses the type checking provided by the compiler and will therefore lead to surprises unless the programmer really was right. This is accompanied by no explanation of how the programmer can find out whether he “really was right”. So the reader is introduced to a certain language mechanism (type casts); warned, rightly, that it is dangerous and will “lead to surprises”; advised implicitly that the mechanism may sometimes be needed; but given no clue as to how to spot the legitimate uses. Such advice is essentially useless; more precisely, it has a negative effect — impressing on the reader that the tool being described, in this case a programming language, is marred by areas of insecurity and uncertainty, and should not be trusted at all. Exceptions Many rules have exceptions. But if you present a software methodology rule and wish to indicate that it may not always apply, you should say precisely what cases justify exceptions. Otherwise the rule will be ineffective: each time a developer runs into a delicate case (that is to say, each time he truly needs your advice), he will be entitled to think that the rule does not apply. Consider the following paragraph from an article about software methodology, coming after the presentation of a rather strict set of rules: The strict version of the class form of the Law of Demeter is intended to be a guideline, not an absolute restriction. The minimization version of the law’s class form gives you a choice of how strongly you want to follow the strict version of the law: the more nonpreferred acquaintance classes you use, the less strongly you adhere to the strict version. In some situations, the cost of obeying the strict version may be greater than the benefits. It is difficult, after reading this extract, to decide how serious the authors are about their own rule; when should you apply it, and when is it OK to violate it? What is wrong in not the presence of exceptions in a general guideline. Because software design is a complex task, it is sometimes inevitable (although always undesirable) to add to an absolute positive “Always do X in situation A” or an absolute negative “Never do Y in situation A” the qualification “except in cases B, C and D”. Such a qualified rule remains an absolute positive or negative: simply, its domain of application Advisory Rules methodology principle In devising advisory rules (positive or negative), use principles, not platitudes. To help make the distinction, examine the rules’ negation. From [Ellis 1990]. From [Lieberherr 1989]