List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:October 21 2009 9:37am
Subject:Re: Coding style changes of 2009-06-26 now in the guidelines
View as plain text  
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
Thread
Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing17 Oct
  • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN17 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesJay Pipes18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius19 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing19 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
        • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
            • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesRoy Lyseng19 Oct
          • RE: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN19 Oct
        • Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing19 Oct
          • re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
            • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing21 Oct
              • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Konstantin Osipov23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Jay Pipes23 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius22 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN23 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius24 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN21 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct