Hi Guilhem,
On 9/27/10 4:33 AM, Guilhem Bichot wrote:
> Davi Arnaut a écrit, Le 25.09.2010 03:31:
>> On 9/24/10 12:22 PM, Mats Kindahl wrote:
>>> In this particular case, we would probably be better off if we could
>>> turn on -std=c89, which disallows C++ comments in C code.
>>>
>>> The downside is that it would of course mean that we have to start
>>> writing standards-compliant C code (oh horrors!). :)
>>
>> I wish that overtime we could focus more on styles and actions, such
>> as this, that have more practical consequences. Over time, discussions
>> about the cosmetic aspects of coding style tend to get very silly.
>
> Since I'm the one who sent the original proposal, I feel a bit targetted
> by the suggestion, so please let me explain.
Relax, do not feel targeted. I was replying to Mats that I tend to like
more practical suggestions, like the one he commented, that are less
prone to personal taste and whose results can be measured. I didn't
attempt to implicitly suggest your proposal was silly. The _discussion_
around it is what can become silly. Do you disagree? :)
> I have worked in MySQL dev for soon 8 years and have respected the
> coding style as requested. But, maybe it's the effect of those 8 years,
> I end up tired of some rules, finding them plain unneeded.
> Why can I write
> int x; // this is an end-of-line comment
FWIW, I do not like this comment style.
> but not
> // this is a comment alone on its line
> ?
I find this one acceptable.
> why does it have to be
> /* this is a comment alone on its line */
> ?
> I don't know. I pointed out the small problems which it causes. And I
I suspect it is a question of uniformity. Style wise, homogeneity is a
good thing.
> find that learning and keeping this rule in mind is an unneeded burden
> put on newly hired developers.
This is not really a burden :) We could also make a "checkpatch" bzr
hook to detect this kind of violation.
> That we should get rid of it in order to simplify our coding style and
> free the brain for something else.
I wonder if we could measure how much space it frees.
> When I made my proposal, I expected to receive only "yes of course"
> feedback without any opposition, and later have this straightforwardly
> approved by the committee and be done with it.
> I didn't expect it to launch a discussion. Conclusion: "you never know"...
Yeah, my point exactly.
> Same for my "true/false instead of TRUE/FALSE" proposal. I am asking
> that we just accept what the C++ standard defines. I think that new devs
> would be better off if they didn't have to learn and remember that they
> must use TRUE/FALSE. That reviewers would be better off if they didn't
> have to watch for use of true/false and reject it.
Yeah. But, for me personally, that's almost automatic nowadays. Also, we
could automate it if we wanted to.
> Again I thought it would get "yes of course" feedback.
Yeah, but it got hijacked into a my_bool discussion...
> I will probably continue making proposals of this kind in the future.
Sure. But if you also, at the same time, propose some way to avoid
misuse, it shortens the discussion scope. For example, let's use C++
style comments but also ensure via a "checkpatch" bzr hook that it won't
be used in C files, or via -std=c89.
>> How about a proposal that new C and C++ code must be
>> standards-compliant? That it must compile warning free? etc. Do you
>> have an idea of how much work is needed to make MySQL compile with
>> -std=c89?
>
> Why not; it would be great improvements. You are free to make those
> proposals, and I see you have already done some real work about that.
> I don't see your proposals exclusive with mine.
> By the way, allowing true/false or //, is not about being standards
> compliant, but close: it would be about being standards _tolerant_.
I think it would help and it would avoid misuse, which is what was
probably behind the said styles.
Regards,
Davi
