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
