Hi!
>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:
<cut>
>> Having a mix of convention in the same code will just cause conflicts
>> and is something that should be strongly discouraged
MARK> Are you against any change to the coding guideline unless it is
MARK> enforced immediately for all code?
Generally yes. If we have a new guideline that is so much better than
what already exists, we should change all the code.
(This is something that I have done several times in the past)
MARK> Existing code already has a mix of conventions for this, including:
MARK> 1) return type int
MARK> 2) return type my_bool and use TRUE for error, FALSE for success
MARK> 3) return type my_bool and use 1 for error, 0 for success
MARK> I want 2) and 3) to gradually be replaced by 1)
I myself prefer 2) becasue:
- By looking at the function prototype you know at once what kind of values
to expect for a function.
- I prefer to have documentation of the code done with types than having to
look at the code for knowing how to process the return value.
- 1) is already used for functions that return many different kind of
return values, all of which should normally have to be handled in
the code.
- For an my_bool function, it's ok to just do a simple if on the
return value:
if (my_bool_function(...)) {}
For a int function this can in many case be a bug.
MARK> 2) Use _Bool for my_bool on platforms that support C99
>>
>> Having both _Bool and my_bool would make the code less portable.
>> Better to stick with with my_bool as we are already using it all over
>> the places.
MARK> Use #define or typedef so that my_bool is implemented by _Bool.
What would that gain us ?
_Bool is less readable than my_bool and we who code MySQL are already
used to the my_bool type.
Regards,
Monty
