876 A SENSE OF STYLE $26.1 There is often a temptation to postpone the application of the rules,writing things casually at first and thinking"I will clean up everything later on;I do not even know how much of this will eventually be discarded".This is not the recommended way.Once you get used to the rules,they do not add any significant delay to the initial writing of the software;even without special tools,it is always more costly to fix the text later than to write it properly from the start.And given the pressure on software developers,there is ever a risk that you will forget or not find the time to clean things up.Then someone who is asked later to take up your work will waste more time than it would have cost you to write the proper header comments,devise the right feature names,apply the proper layout. That someone may be you. Terseness and explicitness Software styles have oscillated between the terse and the verbose.In programming languages,the two extremes are perhaps APL and Cobol.The contrast between the Fortran-C-C++line and the Algol-Pascal-Ada tradition -not just the languages themselves,but the styles they have bred-is almost as stark. What matters for us is clarity and,more generally,quality.Extreme forms of terseness and verbosity can both work against these goals.Cryptic C programs are unfortunately not limited to the famous"obfuscated C"and "Obfuscated C++"contests; but the almost equally famous DIVIDE DAYS BY 7 GIVING WEEKS of Cobol is a waste of everyone's attention. The style that follows from this chapter's rules is a particular mix of Algol-like explicitness(although not,it is hoped,verbosity)and telegram-style terseness.It never begrudges keystrokes,even lines,when they truly help make the software readable;for example,you will find rules that enjoin using clear identifiers based on full words,not abbreviations,as it is foolish to save a few letters by calling a feature disp (ambiguous) rather than display (clear and precise),or a class ACCNT (unpronounceable)rather than ACCOUNT.There is no tax on keystrokes.But at the same time when it comes to eliminating waste and unneeded redundancies the rules below are as pitiless as the recommendations of a General Accounting Office Special Commission on Improving Government.They limit header comments to indispensable words,getting rid of all the non-essential "the"and other such amenities;they proscribe over-qualification of feature names (as in account balance in a class ACCOUNT,where balance is perfectly sufficient);against dominant mores,they permit the grouping of related components of a complex construct on a single line,as in from i:=/invariant i<=n until i=n loop;and so on This combination of terseness and explicitness is what you should seek in your own texts.Do not waste space,as exaggerated size will in the end mean exaggerated complexity;but do not hesitate to use space when it is necessary to enhance clarity Also remember,iflike many people you are concerned about how much smaller the text of an object-oriented implementation will be than the text of a comparable C,Pascal, Ada or Fortran program,that the only interesting answer will appear at the level of a876 A SENSE OF STYLE §26.1 There is often a temptation to postpone the application of the rules, writing things casually at first and thinking “I will clean up everything later on; I do not even know how much of this will eventually be discarded”. This is not the recommended way. Once you get used to the rules, they do not add any significant delay to the initial writing of the software; even without special tools, it is always more costly to fix the text later than to write it properly from the start. And given the pressure on software developers, there is ever a risk that you will forget or not find the time to clean things up. Then someone who is asked later to take up your work will waste more time than it would have cost you to write the proper header comments, devise the right feature names, apply the proper layout. That someone may be you. Terseness and explicitness Software styles have oscillated between the terse and the verbose. In programming languages, the two extremes are perhaps APL and Cobol. The contrast between the Fortran-C-C++ line and the Algol-Pascal-Ada tradition — not just the languages themselves, but the styles they have bred — is almost as stark. What matters for us is clarity and, more generally, quality. Extreme forms of terseness and verbosity can both work against these goals. Cryptic C programs are unfortunately not limited to the famous “obfuscated C” and “Obfuscated C++” contests; but the almost equally famous DIVIDE DAYS BY 7 GIVING WEEKS of Cobol is a waste of everyone’s attention. The style that follows from this chapter’s rules is a particular mix of Algol-like explicitness (although not, it is hoped, verbosity) and telegram-style terseness. It never begrudges keystrokes, even lines, when they truly help make the software readable; for example, you will find rules that enjoin using clear identifiers based on full words, not abbreviations, as it is foolish to save a few letters by calling a feature disp (ambiguous) rather than display (clear and precise), or a class ACCNT (unpronounceable) rather than ACCOUNT. There is no tax on keystrokes. But at the same time when it comes to eliminating waste and unneeded redundancies the rules below are as pitiless as the recommendations of a General Accounting Office Special Commission on Improving Government. They limit header comments to indispensable words, getting rid of all the non-essential “the” and other such amenities; they proscribe over-qualification of feature names (as in account_balance in a class ACCOUNT, where balance is perfectly sufficient); against dominant mores, they permit the grouping of related components of a complex construct on a single line, as in from i := 1 invariant i <= n until i = n loop; and so on. This combination of terseness and explicitness is what you should seek in your own texts. Do not waste space, as exaggerated size will in the end mean exaggerated complexity; but do not hesitate to use space when it is necessary to enhance clarity. Also remember, if like many people you are concerned about how much smaller the text of an object-oriented implementation will be than the text of a comparable C, Pascal, Ada or Fortran program, that the only interesting answer will appear at the level of a