On Fri, Dec 30, 2011 at 3:43 PM, John Gilmore <[email protected]> wrote:
> 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. Ha! That's my kind of logic... ;-) If one option is error-prone, then the alternative must be better... IMHO I think our main objective is that the machine understands the program correctly. So we must not make typos in our programming. I'd love to see statistics, but my assumption is that typing errors are proportional with the amount you type. The justification for typing more than the bare minumum (say symbols of only length 1 and 2) is to make the namespace larger and have the assembler detect your typing errors. Practical reasons normally keep you from using very long names. And DSECTs used in many different modules keep you from using very short names. But making the symbols longer will only help if it increases entropy. So the longer names must be substantially different to prevent a single error produce a valid (but different) identifier. With HLASM we're mostly on our own since very few semantic errors can be detected. While it may sound attractive to have a "standard" that suggests to use PFOO for the pointer to FOO, the assembler will often not catch it when you drop the P by mistake. I think camel case and very long identifiers have become more popular through the use of IDE's where you pick the identifier from a pull-down menu. With this kind of program-by-number development it helps to have descriptive long names to select from. Because you don't type them yourself, the longer names are not more error prone. The frequent need of singleton instances encourages the "standard" to name variables similar to their type - the IDE has the context info to avoid presenting you with the wrong ones in the menu. You can't assume that such practices do well when you have to type it all yourself. Rob
