List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:October 20 2009 11:25pm
Subject:Re: Coding style changes of 2009-06-26 now in the guidelines
View as plain text  
Hi!

>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:

MARK> On Mon, Oct 19, 2009 at 12:01 AM, Ingo Strüwing
> <Ingo.Struewing@stripped> wrote:
>> Hi Mark,
>> 
>> MARK CALLAGHAN, 17.10.2009 20:31:
>> 
>> ...
>>>     *  Functions should return zero on success, and non-zero
> on error,
>>> so you can do:
>>> 
>>> Can this be extended to state that these functions should return int
>>> rather than bool/my_bool? Some functions today use bool/my_bool and
>>> return TRUE on error. I have to read the code for these to figure out
>>> whether TRUE is returned on error.
>> 
>> thanks for the suggestion. Is this a formal request to the MySQL Server
>> coding style government committee?
>> 
>>
> http://forge.mysql.com/wiki/MySQL_Internals_Coding_Guidelines#How_we_maintain_the_server_coding_guidelines
>> 
>> In this case, please add, what the implementation strategy should be:
>> Change all existing code, or let only new code follow the proposal.

MARK> I don't expect existing code to be changed. But it would be nice for
MARK> people to slowly fix things when they edit code. My requests are:
MARK> 1) Use Unix style for functions (return type is int, 0 == success).
MARK> The current rule doesn't mention the return type. Do not use
MARK> bool/my_bool for this with FALSE==errror and TRUE==success in place of
MARK> 1.

Having a mix of convention in the same code will just cause conflicts
and is something that should be strongly discouraged

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> 3) Do not use the literals 0 and 1 in place of FALSE and TRUE

Matter of style, but don't object to it (as long as no one uses this
as an argument that FALSE should mean error).

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