$19.2 DEVISING GOOD RULES:ADVICE TO THE ADVISORS 667 Unfortunately,they are also the least common in the methodological literature, partly for a good reason(for such precise advice,it is sometimes possible to write tools that carry out the desired tasks automatically,removing the need for methodological intervention),but mostly because advisors are too cautious to commit themselves,like a lawyer who never quite answers“yes”or“no”to a question for fear of being blamed for the consequences if his client does act on the basis of the answer. Yet such rules are badly needed: Absolute Positives methodology principle In devising methodological rules,favor absolute positives,and for each such rule examine whether it is possible to enforce the rule automatically through tools or language constructs. Absolute negatives Absolute negatives are a sensitive area.One wishes that every methodologist who followed in Dijkstra's footsteps had taken the same care to justify his negatives as Dijkstra did with the Goto.The following precept applies to such rules: Absolute Negatives methodology principle Any absolute negative must be backed by a precise explanation of why the author considers the rejected mechanism bad practice,and accompanied by a precise description of how to substitute other mechanisms for it. Advisories Advisory rules,positive or negative,are fraught with the risk of uselessness. It is said that to distinguish between a principle and a platitude you must consider the negation of the property:only if it is a principle does the negation still make sense, whether or not you agree with it.For example the often quoted software methodology advice"Use variable names that are meaningful"is a platitude,not a principle,since no one in his right mind would suggest using meaningless variable names.To turn this rule into a principle,you must define precise standards for naming variables.Of course in so doing you may find that some readers will disagree with those standards,which is why platitudes are so much more comfortable;but it is the role of a methodological advisor to take such risks. Advisory rules,by avoiding absolute injunctions,are particularly prone to becoming platitudes,as especially reflected in qualifications of the form"whenever possible"or,for advisory negatives,"unless you absolutely need to",the most dishonest formula in software methodology. The next precept helps avoid this risk by keeping us honest:§19.2 DEVISING GOOD RULES: ADVICE TO THE ADVISORS 667 Unfortunately, they are also the least common in the methodological literature, partly for a good reason (for such precise advice, it is sometimes possible to write tools that carry out the desired tasks automatically, removing the need for methodological intervention), but mostly because advisors are too cautious to commit themselves, like a lawyer who never quite answers “yes” or “no” to a question for fear of being blamed for the consequences if his client does act on the basis of the answer. Yet such rules are badly needed: Absolute negatives Absolute negatives are a sensitive area. One wishes that every methodologist who followed in Dijkstra’s footsteps had taken the same care to justify his negatives as Dijkstra did with the Goto. The following precept applies to such rules: Advisories Advisory rules, positive or negative, are fraught with the risk of uselessness. It is said that to distinguish between a principle and a platitude you must consider the negation of the property: only if it is a principle does the negation still make sense, whether or not you agree with it. For example the often quoted software methodology advice “Use variable names that are meaningful” is a platitude, not a principle, since no one in his right mind would suggest using meaningless variable names. To turn this rule into a principle, you must define precise standards for naming variables. Of course in so doing you may find that some readers will disagree with those standards, which is why platitudes are so much more comfortable; but it is the role of a methodological advisor to take such risks. Advisory rules, by avoiding absolute injunctions, are particularly prone to becoming platitudes, as especially reflected in qualifications of the form “whenever possible” or, for advisory negatives, “unless you absolutely need to”, the most dishonest formula in software methodology. The next precept helps avoid this risk by keeping us honest: Absolute Positives methodology principle In devising methodological rules, favor absolute positives, and for each such rule examine whether it is possible to enforce the rule automatically through tools or language constructs. Absolute Negatives methodology principle Any absolute negative must be backed by a precise explanation of why the author considers the rejected mechanism bad practice, and accompanied by a precise description of how to substitute other mechanisms for it