Re: Whether to return String "True" or "False" instead of 1 or 0

From: Shakespeare <whatsin_at_xs4all.nl>
Date: Fri, 17 Aug 2007 14:02:50 +0200
Message-ID: <46c58e75$0$231$e4fe514c@news.xs4all.nl>

"CrazyKarma" <skalki_at_gmail.com> wrote
> One of the developers had written a function such that it returns a
> string value as either "True" or "False", which was again used in a
> sql context with a decode statement wrapped around it to do something
> else.
>
>
> During code review, I called it out and said that its better to have
> that return a int as 1 or 0, so that its flexiable in future to return
> more values and also put to a comment to say what each value stands
> for.
>
> Developer disagreed saying that his method is more readable and either
> way we will have to change the code if we have to make it return
> different values in future.
>
> I agree that the code is more readable but extent of change presuming
> that the data fetched may be different in future is less with my
> change.
>
> also believe string equality checks is exposed to case sensitivity
> issues.
>
> what do you all think?
>

I would prefer to define constants somewhere (like in a package specification) like
const c_true = 1;

c_false = 0; (though I would prefer to use boolean values here)
c_red = 'Red' ;
c_blue = 'Blue';

(or the other way around, whatever you want) and only use constant names in the code. This will reveal typo's while compiling, in stead of while executing your code.

I don't see why int values are more flexible than char values; if you want to add another value you can do that in both cases. Case sensitivity, typing errors etc are a point here!

The named constant method will only work within one environment, though, and if you mix e.g. pl/sql with c++ , xml etc you would have to maintain the constants in both languages, but these constant definition packages or libraries or whatever could be generated from a common source with easy to write generators.

Shakespeare Received on Fri Aug 17 2007 - 07:02:50 CDT