Re: constant string array

["Ken Garlington" <Ken.Garlington@computer.org>]

"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:B6A1A9B09E52D31183ED00A0C9E0888C469941@nctswashxchg.nctswash.navy.mil..
.
: -----Original Message-----
: From: Robert Dewar [mailto:robert_dewar@my-deja.com]
:
: >> As in "if () then", no matter what "()" contained.
:
: >Well the () are useless noise REGARDLESS of what they enclose
: >since there is no precedence issues etc in this case.
:
: What case?  You don't even know what case I'm talking
: about.  If () contains, "a * b + c", does it now deal
: with precedence.  You seem to think I'm talking about
: simple cases here.  I'm talking about all cases.
: For consistency, the decision was made, not by me if I
: haven't made that clear yet, to use parens in all cases.
:
: >> They wanted consistency and it wasn't worth arguing,
: >> because "if (success) then" is no harder to read than
: >> "if success then"
: >
: >There is no more justification for this than a silly rule
: >that requires all right hand sides to be in parentheses.
: >The argument could equally well be that
: >
: >   a := (success);
: >
: >is no harder to read then
: >
: >   a := success;
:
: Wrong!  Because we consistently code:
:
:    a := success;
:
: not
:
:    a:= (success);

But, if you consistently coded a := (success); then it would by OK, right?

I say, why stop at one set? I think a nice rule would be to encode tests in
double parentheses, similar to label constructs, i.e.

if ((a * b + c)) then
  ...
end if;

so that, if you're doing structural test coverage analysis, you can find the
essential elements easily. Wouldn't that just be a lovely standard?