Coding Style

This is a home page of the MySQL Server coding style government committee.

The members of the committee are:

Contents

[edit] Proceedings

[edit] 2010-10-27: 7 proposals

7) Document function calling convention and how to return errors.

8) Use _Bool for my_bool on platforms that suport C99

9) Do not use literals 0 and 1 in place of FALSE and TRUE

10) Use true/false rather than TRUE/FALSE in C++

11) Every header file should be self-sufficient

12) Allow C++ single-line comments

13) Replace bfill and bzero with memset

The discussion/conclusion can be found here: googlewave

[edit] 2010-06-23: 5 proposals

1) Avoid trailing spaces

2) Deprecate UPPERCASE typedefs

3) Document indentation rules for namespaces and inline functions

4) Doxygen comments precede function declarations, not definitions

5) All headers must have header guards

The discussion/conclusion can be found here: googlewave

[edit] 2009-06-26: 2 indentation proposals

[edit] Agenda

1) Remove switch alignment exception. Description of the proposal and discussion: http://lists.mysql.com/internals/36385

The proposal, after some details were specified out, was accepted by 5 votes out of 6. The accepted switch style is:

 switch (a) 
 {
 case 1:
   statement;
 case 2:
   {
     statements;
   }
 }

Implementation strategy: start using the new rules in new code. Keep the old code intact.

2) Use function parameter names in declarations. Discussion: http://lists.mysql.com/internals/36404

The proposal was accepted by majority of votes (5 out of 6).

Summary: In function/method declarations, always provide names of arguments:

Restore_info* prepare_for_restore(String *backupdir,
                                  LEX_STRING orig_dir,
                                  const char *query,
                                  bool with_compression,
                                  const char *comment);

Implementation strategy: apply in new code, leave old code intact.

[edit] 2009-03-13: Optimiser team exception

Sergey Petrunia writes:

There should be no "fix coding style" changes to the existing [optimiser] code. The only exception is when the fix is done by those who then will accept full responsibility for the touched code and will not try to push the this responsibility out to somebody else.

It was agreed that the optimiser team must be able to decide what's the best way to maintain the optimiser code.

[edit] Pending propsals

[edit] References

  1. MySQL_Internals_Coding_Guidelines
  2. How_to_Create_Good_Tests

Retrieved from "http://forge.mysql.com/wiki/Coding_Style"

This page has been accessed 2,114 times. This page was last modified 09:25, 28 September 2011.

Find

Browse
MySQLForge
Main Page
Current events
Recent changes
Random page
Help
Edit
Edit this page
Editing help
This page
Discuss this page
Post a comment
Printable version
Context
Page history
What links here
Related changes
My pages
Special pages
New pages
File list
Statistics
Bug reports
More...