Edward Jaffe wrote <begin snippet> . . . I will painstakingly plan and create camel case fields in a control block and then later see code referencing those fields using the wrong case (due to typos, dyslexia, or what have you) . . . </end snippet>
This makes the case for using the break character, '_', instead of camel case that Shane and I tried to make earlier in this thread. The question which looks better is clearly subjective; the question which is more error-prone is settled. Case control is a more complicated issue. In situations like the one EJ describes I have found the two options that the HLASM already supports, viz., o CASE | NOCASE, and o MACROCASE|NOMACROCASE entirely adequate; but this is because I work in a very small group of usually two and never more than three people in which my taste is, if not controlling, very influential. Their defect as control mechanisms is that they are options. They can be specified differently by different programmers or even by the same programmer on different occasions. It is not, however, clear to me that this can be otherwise. The hoary ALL-CAPS tradition of the keypunch-impact printer era is dying hard. It is not yet even moribund. Moreover, phantasies aside, I should not finally wish to enforce my taste upon others; and I would noisily oppose having their [dubious] taste imposed upon me. John Gilmore, Ashland, MA 01721 - USA
