List:Internals« Previous MessageNext Message »
From:Ingo Strüwing Date:March 18 2009 11:43am
Subject:Re: [style] change proposal: function parameter names in headers
View as plain text  
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.

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.

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? 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.

Regards
Ingo
-- 
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028
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