670 ON METHODOLOGY $19.2 If it is baroque,fix it The advice on C++type casts quoted earlier illustrates a general problem of advisory negatives:recommendations of this kind owe their existence to limitations of the underlying tool or language.For a perfect tool we would never have to give advisory negatives;every facility would be accompanied by a clear definition of when it is appropriate and when it is not-a criterion of the absolute kind,not advisory.No tool is perfect,but for a decent one the number of advisory negatives should remain very small. If in teaching the proper use of the tool you find yourself frequently resorting to comments of the form "Try to stay away from this mechanism unless you absolutely need it",then most likely the problem is what you are teaching about,not your teaching of it. In such a case one should abandon trying to give advice,and improve the tool instead,or build a better one. Typical phrases that signal this situation are ..unless you know what you are doing ..unless you absolutely have to. Avoid.…ifyou can. Try not to... It is generally preferable not to .. Better stay away from... The C/C++/Java literature has a particular fondness for such formulae.Typical is this Advice from [Bright advice:"Don't write to your data structure unless you have to",from the same C++expert 1995].See page 516 who in an earlier chapter was waming us against too much use of O-O mechanisms. This advice is puzzling.Why would developers write to a data structure for no reason? Rampant Problem of Programmers Writing to Data Structures When They Don't Have (Imaginary media To Worries US Software Industry.Why do they do it?Says Jill Kindsoul (not her real report.) name),a Senior Software Engineer in Santa Barbara,California:"My heart goes out to the poor things.It canfeel so lonely out there in swap space!I consider it my duty to write to each one of my objects'fields at least once a day,even ifit's just with its own previous value.Sometimes I come back during the week-end just for it."The actions of programmers like Jill are a growing concern for the principal software vendors,all rumored to have set up special task forces to deal with the issue. Another case of trying to address language flaws through methodological advice- “A simple notion of making language users responsible for someone else's errors-was cited in an earlier book",page 221. chapter:the Java designers'recommendation ("a programmer could still mess up the object...")against using direct field assignments a.x=y,in violation of basic information hiding principles.It is a surprising approach,if you think a construct is bad,and just happen to be designing a programming language,to include the construct anyway and then write a book enjoining the language's future users to avoid it. The "Law of Demeter"cited earlier also provides an example.It restricts the type of "Exceptions".page x,in a callx.(.)appearing in a routiner of a class C,to:types of arguments ofr;types 668. of attributes of C;creation types (types of u in !!u...)for creation instructions appearing in670 ON METHODOLOGY §19.2 If it is baroque, fix it The advice on C++ type casts quoted earlier illustrates a general problem of advisory negatives: recommendations of this kind owe their existence to limitations of the underlying tool or language. For a perfect tool we would never have to give advisory negatives; every facility would be accompanied by a clear definition of when it is appropriate and when it is not — a criterion of the absolute kind, not advisory. No tool is perfect, but for a decent one the number of advisory negatives should remain very small. If in teaching the proper use of the tool you find yourself frequently resorting to comments of the form “Try to stay away from this mechanism unless you absolutely need it”, then most likely the problem is what you are teaching about, not your teaching of it. In such a case one should abandon trying to give advice, and improve the tool instead, or build a better one. Typical phrases that signal this situation are ... unless you know what you are doing. ... unless you absolutely have to. Avoid ... if you can. Try not to ... It is generally preferable not to ... Better stay away from ... The C/C++/Java literature has a particular fondness for such formulae. Typical is this advice: “Don’t write to your data structure unless you have to”, from the same C++ expert who in an earlier chapter was warning us against too much use of O-O mechanisms. This advice is puzzling. Why would developers write to a data structure for no reason? Rampant Problem of Programmers Writing to Data Structures When They Don’t Have To Worries US Software Industry. Why do they do it? Says Jill Kindsoul (not her real name), a Senior Software Engineer in Santa Barbara, California: “My heart goes out to the poor things. It can feel so lonely out there in swap space! I consider it my duty to write to each one of my objects’ fields at least once a day, even if it’s just with its own previous value. Sometimes I come back during the week-end just for it.” The actions of programmers like Jill are a growing concern for the principal software vendors, all rumored to have set up special task forces to deal with the issue. Another case of trying to address language flaws through methodological advice — making language users responsible for someone else’s errors — was cited in an earlier chapter: the Java designers’ recommendation (“a programmer could still mess up the object…”) against using direct field assignments a ● x := y, in violation of basic information hiding principles. It is a surprising approach, if you think a construct is bad, and just happen to be designing a programming language, to include the construct anyway and then write a book enjoining the language’s future users to avoid it. The “Law of Demeter” cited earlier also provides an example. It restricts the type of x, in a call x ● f (...) appearing in a routine r of a class C, to: types of arguments of r; types of attributes of C; creation types (types of u in !! u …) for creation instructions appearing in Advice from [Bright 1995]. See page 516. (Imaginary media report.) “A simple notion of book”, page 221. “Exceptions”, page 668