Glenn writes:
> I haven't found the "greatly increased...maintainability" claim above to be
> true in my own experience. In fact, it was my desire to *improve*
> maintainability which inspired me to switch several years ago to the style
> shown above.
Well ,you read English ,much?
Well, you read English, much?
Notice the difference in readability? The exact difference in readability
is in source code as well as in English (and other languages).
> I got burned on more than one occasion by adding an additional parm at the
"burned" means: syntax error. Each style is *just as susceptible* to the
same kind of trivial syntax problem.
BTW, another readability reason is:
foo ( xxx
, yyy)
The compiler can't fully parse the first parameter until it's read the
second line ... which could result in an error messge misleadingly
pointing at the "yyy" line instead of the "xxx" line.
> In my own code, it's much more common to add a parm to the end than
> to delete the first parm; the "comma-before" style supports the former
> well, while the "comma-after" style supports the latter.
That's why I use a good editor....jump to the ")" and press <Insert> and
start typing ", yyy" (or, "," <return> <indent> (if needed with editor)
"yyy")
I don't make programming style recommendations lightly...I've got a
couple of million lines of history behind them.
Here's an example from SPL showing the "compiler printed the next line
before spotting the problem":
1 00000 0 begin
2 00000 1
3 00000 1 integer i;
4 00000 1 real x;
5 00000 1
6 00000 1 procedure p (b, j); value b, j; real b; integer j;
7 00000 1
8 00000 1 begin
9 00000 2 end;
10 00000 1
13 00000 1 p (i, i);
^
***** ERROR #001 ***** SIZE INCOMPATIBILITY
14 00003 1
15 00003 1 p (i
16 00003 1 , i);
^
***** ERROR #002 ***** SIZE INCOMPATIBILITY SEE 13
17 00006 1
18 00006 1 end.
PRIMARY DB STORAGE=%003; SECONDARY DB STORAGE=%00000
Now, many compilers have logic that attempts to compensate for this problem.
Pascal/iX, for example, is pretty good about suppressing printing the next
line as in:
0 7.000 0 procedure p (b : boolean; j : integer);
3 8.000 0
3 9.000 1 begin
3 10.000 1 end;
3 11.000 0
1 12.000 1 begin
1 13.000 1
1 14.000 1 p (i
^
**** ERROR # 1 ACTUAL PARAMETER NOT COMPATIBLE WITH FORMAL PARAMETER (208)
2 15.000 1 , i);
However, not all compilers are, and it isn't clear if Pascal/iX is 100%
effective in this area.
Also, consider the following code on your screen (or printed page):
...
p (i
----------- end of screen/page -----
Kind of hard to read, yes? Yes. The reader doesn't know until they look
at the next page *what* the resolution of that parameter is going to be.
Contrast that to:
...
p (i,
----------- end of screen/page -----
A single character makes an amazing difference.
It isn't just a matter of style, it's simply a mistake that may
infrequently save you some keystrokes, but can cost you someday.
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler/
|
