List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:April 8 2009 8:27pm
Subject:Re: [style] change proposal: function parameter names in headers
View as plain text  
Hi!

<cut>

Ingo> 1. The switch exception.

Ingo> We write most blocks like so:

Ingo>   keyword (...)
Ingo>   {
Ingo>     ...
Ingo>   }

Ingo> Only for switches we write:

Ingo>   switch (...) {
Ingo>   ...
Ingo>   }

Ingo> While there may be reasons regarding syntactical differences between
Ingo> switch blocks and other blocks, I wonder if we write code for a
Ingo> scientific document, that tries to emphasize syntax elements, or for the
Ingo> pleasure of humans. If we aim for the latter (I do), it is good to give
Ingo> these blocks a common "look". I know that there are many people, who are
Ingo> used to see the opening brace like in the switch example above. They may
Ingo> be very disturbed by the other style. So does writing some blocks one
Ingo> way and some the other way try to please both camps a little? I learned
Ingo> that I can become used to a coding style, which I even dislike. So I
Ingo> think it would be better to force one camp to become used to what they
Ingo> dislike, than to mix styles, just to somewhat please both. BTW, I found
Ingo> 95 switches in non-storage server code (6.0) that do not follow the
Ingo> "switch exception" (and 469 that do follow it). Following my proposal
Ingo> will increase the chaos for some time, but finally most switches will
Ingo> have been touched and thus converted to the new style.

Or, as it should actually be done, convert all the switches that has
violated the current coding style.

I think it's wrong to compare for and switches as they are not similar
strictures;  for is a structure that ends when the { start. The switch
structure doesn't end there but continues inside the {.

The point is that switch and case should match in the same row, to
keep things readable.  In my mind this is much more important than
aligning the {, which is why we did once decide upon the current
coding style.

The major issue is to keep the code easy to read, not to follow
arbitrary rules depending on one single aspect of the code.

Regards,
Monty
Thread
coding style change proposal: function parameter names in headersIngo Strüwing17 Mar
  • Re: coding style change proposal: function parameter names inheadersSergei Golubchik17 Mar
    • Re: coding style change proposal: function parameter names in headersMARK CALLAGHAN17 Mar
      • Re: coding style change proposal: function parameter names in headersJay Pipes17 Mar
      • [style] change proposal: function parameter names in headersKonstantin Osipov17 Mar
    • Re: coding style change proposal: function parameter names in headersIngo Strüwing17 Mar
      • Re: coding style change proposal: function parameter names inheadersSergei Golubchik17 Mar
  • [style] change proposal: function parameter names in headersKonstantin Osipov17 Mar
    • Re: [style] change proposal: function parameter names in headersIngo Strüwing17 Mar
    • Re: [style] change proposal: function parameter names in headersMats Kindahl18 Mar
      • Re: [style] change proposal: function parameter names in headersKonstantin Osipov18 Mar
        • Re: [style] change proposal: function parameter names in headersMARK CALLAGHAN18 Mar
      • Re: [style] change proposal: function parameter names in headersIngo Strüwing18 Mar
        • Re: [style] change proposal: function parameter names in headersMats Kindahl18 Mar
          • Re: [style] change proposal: function parameter names in headersReggie Burnett23 Mar
        • Re: [style] change proposal: function parameter names in headersMichael Widenius8 Apr