Re: Avoiding Booleans & Danny Thorpe

Hi Jim,

I always use named constants for parameters, I would have, just as an
example:
const
NewFileIfNotExist = true;
begin
CreateFile(NewFileIfNotExist);

That way you do know what the parameter means, and you don't need to create
an enumeration
just to make things more readable, and it causes no run time penalty either.

-- Larry Maturo


"Jim Rowell" <x@xxxxx> wrote in message
news:4364c6c0$1@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> "Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
> news:4364b4c0@xxxxxxxxxxxxxxxxxxxxxxxxx
>> I think that
>>
>> CreateFile(cmCreateNew);
>>
>> is much more readable than
>>
>> CreateFile(true);
>>
>> With the latter one I don't have any clue what's the paramter for.
>>
>
> You do if you are reading it inside of the ide which is generally the
> case.
> Nonetheless, I was thinking more along the lines of their use in
> properties
> rather than parameters. I'd say that for parameters they *do* make sense
> instead of booleans and I do prefer them. OTOH, just like the use of type
> prefixes, the ide itself can tell you what you want to know.
>
>>
>> And why is using enumerations "silliness" and decreases code quality ?
>> I strongly doubt that.
>>
>
> Again, I wasn't thinking about their use in parameters (and thank you for
> bringing that up). I was thinking about gobs of boolean properties with
> only
> two possible states. Spattering the code with a bunch of state definitions
> is not needed. What is needed are carefully chosen names. I was mainly
> looking at the example for UI use given in the article where radio buttons
> are heralded over checkboxes. That was mainly what brought the word forth
> from my lips. <g>
>
> --
> Jim Rowell
>
>


.

Quantcast