Re: Service program / procedure design and naming conventions

On Fri, Aug 4, 2017 at 3:34 PM, <dlclark@xxxxxxxxxxxxxxxx> wrote:

I'm genuinely curious: Why do you suggest that your example is more
streamlined than mine? I actually started with returning an indicator,

but

I felt like I'd have to name the procedure "PromptWindowOrgSelected",

which

seemed an odd name to me:
If PromptWindowOrgSelected(...);
// do stuff
Endif;

I think that service procedure name would be perfect for when
returning an indicator. Keep it.

That's my vote as well. You see this style (returning a Boolean, and
naming the function accordingly) in lots of programming languages.

I can appreciate that the string return values are kind of
self-documenting, but they are also a bit less foolproof. Not everyone
is fastidious about upper- and lowercase for example, especially since
the rest of the language isn't case-sensitive. 'Selected' is not the
same as 'selected'. 'Canceled' is not the same as 'Cancelled' (even
though both are valid English spellings!). You KNOW that this kind of
thing is going to mess someone up someday.

I guess you could guard against this to some degree by turning them
into named constants, but that's adding more complexity and
brittleness. Unless you need more than True/False, just go with the
simple Boolean way.

John Y.