Kostja,
thanks for bringing this up!
I can raise a few issues:
1. switch style should be more specific. (I saw 4 different styles on a
brief scan of sql_select.cc).
2. "space" advice for bitwise operators missing.
3. How does class JOIN fit into the coding rules?
4. How do we handle "modern" C++ (templates, namespaces, exceptions,...)
Regards,
Roy
Konstantin Osipov wrote:
> Hello,
>
> As a follow up to the MySQL University session on the coding
> style today, let me present a proposal for the process around it
> to your criticism.
>
> To those who missed the session: the main idea with the server
> coding style I advocate is that we need to revive it, make it a
> living document.
>
> The proposal below allows for flexibility within technical teams
> -- either to appoint a coding style captain, or vote on every
> change separately. A team can decide to share a coding style with
> another team.
> The main point is that the new process allows to introduce
> changes, and assigns out responsibilities, too.
>
> Coding style.
> -------------
>
> All code contributed to the server must adhere to a coding
> style. Since many parts of the server historically originate from
> different development environments, it seems unnecessary to demand
> that all technical teams follow the same style. Besides, the
> existing code base doesn't satisfy this requirement.
>
> Taking this observation into account, the following procedure is
> suggested:
>
> 1. A member of the server team is assigned to oversee the coding
> style matters. Responsibility of this person is to ensure that
> each technical team maintains and adheres to a coding
> style, according to these procedures. Any violations or
> difficulties with are to be brought up by this person with
> server management.
>
> 2. It's up to a technical team (replication, optimizer, etc) to come
> up with their coding style.
> However, in all teams:
> * it should be applied consistently to all source files and
> directories maintained by the team
> * the style must be documented in the MySQL Internals Manual.
> In particular, the scope of the application should be
> documented and unambiguous. A process to make amendments
> to the style should be accepted by the team and documented as
> well.
> * the team has an appointed person to ensure that the coding
> style is followed. This person is responsible also is responsible
> for ensuring that the coding standard is amended according to
> the agreed procedure.
> Example:
>
>
> The server core teams (the runtime and the optimizer teams)
> maintain all files in sql/, libmysql/, mysys/ and strings/
> directories of the server.
>
> The coding style is documented at:
> http://forge.mysql.com/wiki/MySQL_Internals_Coding_Guidelines
>
> The person in the team(s) to ensure that the coding style is
> followed is <name> (needs to be appointed).
>
> The process to make amendments to the coding style is <missing
> currently>.
>
> Thanks,
>
