I often find that to be the case, too (I guess the fovea can only
accommodate so many characters at a time), but I'm not so sure it's a
good thing. In the majority of MUMPS I've seen in the existing code
base, the basic semantic unit has generally been the command. In
other words, there is an awful lot of "chatter" in the code, which
tends to be highly procedural without being highly structured, at
least in an essential way.
To put it a little differently, when I scan a piece of existing MUMPS
code, I see something like: "Okay, do this, and then do this, and if
such and such, do that..." When the basic unit of meaning of a
program are different, it may well scan differently, and whatever
cognitive advantage gained from the abbreviated commands is lost. A
good hardware analogy is an instruction pipeline (abbreviated
commands make it easier to keep the pipeline full). Instruction
pipelines work well for straight line code, but not terribly well
with code not fitting this model. It's interesting: I've had people
tell me my code is hard to read (probably for just this reason), but
the interesting irony is that I often find their code hard to read, too!
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Without the requirement of mathematical aesthetics a great many
discoveries would not have been made."
-- Albert Einstein
On Aug 13, 2005, at 9:23 AM, James Gray wrote:
I will also add one more comment on the use of command
abbreviations. When programmers put multiple commands on the same
line and avoid the use of one letter variable names, the code is
easier to read for me if the commands are just one letter as it is
easy to quickly sort out the commands and arguments through a
process of pattern recognition. The code is actually easier to
read if programmers put one command per line as a rule. If that
was SOP then the advantage of one letter commands would go away.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
