List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:March 18 2009 3:11pm
Subject:Re: [style] change proposal: function parameter names in headers
View as plain text  

Ingo Strüwing wrote:
> Hi Mats,
> 
> Mats Kindahl, 18.03.2009 09:16:
> 
>> Hi all!
>>
>> One thing that I am missing is a rationale... it is very hard to make a decision
>> on why a particular style should be implemented, unless there is some kind of
>> reason to why it should be implemented.
> 
> coding style is mainly a matter of taste and very subjective. There are
> very few style elements that can be reasoned so that it is not
> attackable, if any. So I think it is fine to change a style element if a
> majority "feels" it "sounds" "nice". A rationale is not required, though
> it may improve the chances to receive one or two more votes.

I do not agree, but that is because we have different ideas of what is part of a
coding style. I find brace placement or use of whitespace irrelevant since, as
you say, it is a matter of personal taste and does not affect readability
(assuming that the programmer sticks to one of the widely accepted styles).

This is also the reason to why I am reluctant to change such things unless there
is a good reason to do it (I'm happy with any of the widely accepted styles, as
long as the code is readable).

> That having said, I'm going to waste my time and those of the readers,
> trying to reason something, which is decided by personal preference,
> familiarity, taste, habit, and perhaps even personal relationship to the
> one who made the proposal. Reasons regarding coding style exist just to
> pretend a scientific mind. Attempting to reason a wish is the only basis
> to make the wish attackable. I would prefer not to have a long
> discussion on alleged arguments, but just a short vote. Anyway, I also
> feel the pressure to pretend a rational mind, so here I go:
> 
> 1. The switch exception.
> 
> We write most blocks like so:
> 
>   keyword (...)
>   {
>     ...
>   }
> 
> Only for switches we write:
> 
>   switch (...) {
>   ...
>   }
> 
> While there may be reasons regarding syntactical differences between
> switch blocks and other blocks, I wonder if we write code for a
> scientific document, that tries to emphasize syntax elements, or for the
> pleasure of humans. If we aim for the latter (I do), it is good to give
> these blocks a common "look". I know that there are many people, who are
> used to see the opening brace like in the switch example above. They may
> be very disturbed by the other style. So does writing some blocks one
> way and some the other way try to please both camps a little? I learned
> that I can become used to a coding style, which I even dislike. So I
> think it would be better to force one camp to become used to what they
> dislike, than to mix styles, just to somewhat please both. BTW, I found
> 95 switches in non-storage server code (6.0) that do not follow the
> "switch exception" (and 469 that do follow it). Following my proposal
> will increase the chaos for some time, but finally most switches will
> have been touched and thus converted to the new style.

So your argument is consistency with other uses of braces, which does have an
objective value since it does not require us developers to keep a lot of
exceptions regarding placement of braces in our heads.

> 2. Function parameter names in headers
> 
> We did already have a short discussion about this. It turned out that it
> is better for "the machine" not to have this. But for a human it can
> still be easier to read headers and extract interface declarations from
> there. So the question is again: Do we want to please machines, or
> humans?

This is not a matter of pleasing anybody, it is a matter of being able to work
efficiently with the code and be able to focus on the problem, not the layout.
For that reason, such things as "pleasing the machine" *may* be important
because the tools are not good enough (not saying that they are in this case).

> And we have at least two categories of humans: Those who know
> every MySQL function and method by heart, and those that often need to
> search for a function or method that may be appropriate for a current
> need. If the former group rules, who requires to put less information
> into header files, so that the machine can better handle it, the life
> for the latter ones becomes even more difficult. I did already mention
> my most frequent use case: The class String. When I want to do something
> with a String, I usually need to scan through the interface declaration
> in sql_string.h to find the most appropriate method for the purpose. If
> the methods wouldn't have parameter names, just types, I would need to
> lookup sql_string.cc too. Opening sql_string.cc from the beginning,
> would require a lot of scrolling, and perhaps even missing a method or
> two as they are all of very different length, some have function
> comments, some don't. And after all, some methods are defined in
> sql_class.h even and not in sql_class.cc. So scanning sql_class.h seems
> much more efficient to me. Having all parameter names there makes the
> lookup of the method definition unnecessary in many cases and thus is a
> good time saver. For me. Those, who use a tool that confuses
> declarations with definitions, unless the declarations omit the
> parameter names, may disagree.

I think this is a good argument, and not very subjective. It is a matter of
being able to work efficiently with the code.

Just my few cents,
Mats Kindahl

-- 
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
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