From: Thomas Rast <trast@student.ethz.ch>
To: <konglu@minatec.inpg.fr>
Cc: Leila <muhtasib@gmail.com>, <git@vger.kernel.org>
Subject: Re: [PATCH] git-status: Show empty directories
Date: Sun, 10 Jun 2012 11:01:22 +0200 [thread overview]
Message-ID: <87haujr15p.fsf@thomas.inf.ethz.ch> (raw)
In-Reply-To: <20120609234717.Horde.I9rYUXwdC4BP08RlFRO2w_A@webmail.minatec.grenoble-inp.fr> (konglu@minatec.inpg.fr's message of "Sat, 09 Jun 2012 23:47:17 +0200")
konglu@minatec.inpg.fr writes:
> Thomas Rast <trast@student.ethz.ch> a écrit :
>
>> Leila <muhtasib@gmail.com> writes:
>>
>>>> The structure is
>>>> if (...) {
>>>> /*code*/
>>>> } else {
>>>> /*code*/
>>>> }
>>>>
>>>> Do not forget braces in the "else" part as the firt block needs it.
>>>
>>> I was under the impression that one liners didn't require parenthesis
>>> according to the style guidelines. I didn't realize that if the 'if'
>>> required it, then the else required it. I will make that change and
>>> remember it for the future. Thanks!
>>
>> It's not required, there's plenty of precedent, even one case within
>> wt-status.c, of '} else'. Try running
>>
>> git grep '} else$'
>
> It's not because "there's plenty of precedent" that we should not try
> to improve the format of the code. That's why there're coding style
> rules so that we can keep the improvements consistent.
Yeah, and the rules (Documentation/CodingGuidelines) say
- We avoid using braces unnecessarily. I.e.
if (bla) {
x = 1;
}
is frowned upon. A gray area is when the statement extends
over a few lines, and/or you have a lengthy comment atop of
it. Also, like in the Linux kernel, if there is a long list
of "else if" statements, it can make sense to add braces to
single line blocks.
I'm not the one who wrote them, but I'm taking the last sentence to mean
that you should not put the braces unless the omission will break the
vertical alignment of the 'else if' chain.
BTW, there are plenty of cases in git where it is better to stick to the
existing style of the file instead of the CodingGuidelines, unless you
are willing to clean up the file first (and nobody else works on it).
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2012-06-10 9:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-09 19:40 [PATCH] git-status: Show empty directories Leila Muhtasib
2012-06-09 20:13 ` konglu
2012-06-09 21:08 ` Leila
2012-06-09 21:14 ` Thomas Rast
2012-06-09 21:24 ` Leila
2012-06-09 21:47 ` konglu
2012-06-10 9:01 ` Thomas Rast [this message]
2012-06-10 9:46 ` konglu
2012-06-10 14:20 ` Leila
2012-06-11 15:08 ` Junio C Hamano
2012-06-10 7:15 ` Junio C Hamano
2012-06-10 16:02 ` Leila
2012-06-10 18:12 ` konglu
2012-06-10 18:17 ` Leila
2012-06-11 16:57 ` Junio C Hamano
2012-06-11 18:51 ` Leila
2012-06-11 19:00 ` Leila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87haujr15p.fsf@thomas.inf.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=konglu@minatec.inpg.fr \
--cc=muhtasib@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).