List:Internals« Previous MessageNext Message »
From:Davi Arnaut Date:September 28 2010 11:40am
Subject:Re: [STYLE] could we allow // for comments alone on their line?
View as plain text  
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
Thread
[STYLE] could we allow // for comments alone on their line?Guilhem Bichot23 Sep
  • Re: [STYLE] could we allow // for comments alone on their line?Joerg Bruehe24 Sep
    • Re: [STYLE] could we allow // for comments alone on their line?Mats Kindahl24 Sep
      • Re: [STYLE] could we allow // for comments alone on their line?Mark Leith24 Sep
      • Re: [STYLE] could we allow // for comments alone on their line?Davi Arnaut25 Sep
        • Re: [STYLE] could we allow // for comments alone on their line?Mats Kindahl25 Sep
          • Re: [STYLE] could we allow // for comments alone on their line?Davi Arnaut26 Sep
        • Re: [STYLE] could we allow // for comments alone on their line?Guilhem Bichot27 Sep
          • Re: [STYLE] could we allow // for comments alone on their line?Martin Hansson28 Sep
          • Re: [STYLE] could we allow // for comments alone on their line?Davi Arnaut28 Sep
  • Re: [STYLE] could we allow // for comments alone on their line?Ingo Struewing24 Sep
  • [STYLE] could we allow // for comments alone on their line?Michael Widenius30 Sep