List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:March 18 2009 8:16am
Subject:Re: [style] change proposal: function parameter names in headers
View as plain text  
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.

For the two given proposals, I don't really see any form of rationale (well, the
second one actually have a sort of "it is easier to read the prototype than to
read the source file").

I think that it is important that we have answers to "What?", "Why?", and "How?"
for each proposal. If either one of these three is missing, any decision will at
best be seen as arbitrary and be questioned even after it has been approved.

Just my few cents,
Mats Kindahl

Konstantin Osipov wrote:
> Hello Ingo,
> 
> Thank you for this change request. I shall record it as the first
> change request here:
> 
> http://forge.mysql.com/wiki/Coding_Style
> 
> Each change proposal needs to have an implementation.
> 
> How do you suggest we enforce this change? Do we inspect and
> change the old code? Do we apply the rule in new code only?
> 
> * Ingo Strüwing <Ingo.Struewing@stripped> [09/03/17 15:26]:
> 
>> I propose to demand function parameter names in header files.
>>
>> We do not document functions in header files. The documentation goes to
>> the C/C++ file where it is defined.
>>
>> With parameter names in header files, one would not need to look up the
>> source file for every function call.
>>
>> Example:
>>
>>   Restore_info* prepare_for_restore(String*, LEX_STRING,
>>                                     const char*, bool,
>>                                     const char*);
>>
>> This declaration forces me to look into kernel.cc whenever I want to
>> call it.
>>
>>   Restore_info* prepare_for_restore(String *backupdir,
>>                                     LEX_STRING orig_dir,
>>                                     const char *query,
>>                                     bool with_compression,
>>                                     const char *comment);
>>
>> In this case there is a good chance that I do not need to consult the
>> function comment in the source file.
> 

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