Re: Define field as an indicator in D-specs

On 12/6/2013 1:15 PM, Englander, Douglas wrote:

I'm not confused.

I am. I'm not sure if we're discussing named constants vs 'magic numbers'

if SQL_NODATA;
vs
if SQLSTT = '02000';

...or named constants vs initialised variables.

d SQL_NODATA c const('02000')
d SQL_NODATA 5a inz('02000')

... or the use of a named constant in lieu of *ON.

I don't understand why someone would want to
write more code than they have to.

For me personally, when I see *ON in a piece of code I read it as TRUE.
So I myself would probably not code d TRUE c const('*on'). But I
wouldn't give it a moment's thought if a colleague felt like doing so.
Does anyone find a material difference between

eval customerWinsIpad = *on
vs
eval customerWinsIpad = TRUE

They both seem equally illuminating to me. But, to Booth's original
question (see the subject line):

if customerWonThisYear = *on (or TRUE or implied *on)
// not eligible until next year
endif

seems much better than:
if *in20 = *on (or TRUE or implied *ON)
// not eligible until next year
endif

...especially if indicator 20 is reused elsewhere. The difference
between these two code blocks is that the first one requires a d-spec to
define customerWonThisYear s n. I myself don't find that burdensome.

Did I misunderstand?
--buck