From: Albert Cahalan <albert@users.sf.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: Coding style: do_this(a,b) vs. do_this(a, b)
Date: 17 Aug 2004 13:07:48 -0400 [thread overview]
Message-ID: <1092762468.5759.1524.camel@cube> (raw)
In-Reply-To: <20040817164046.GA19009@elf.ucw.cz>
On Tue, 2004-08-17 at 12:40, Pavel Machek wrote:
> Hi!
>
> > > Coding style document is not consistent with
> > > itself on whether there should be space after
> > > ","... This makes it standartize on ", " option.
> >
> > You can read it both ways, right? It's easy.
> > I can't even see the difference unless I'm
> > looking for it.
>
> Well, you maybe can't tell the difference, but I definitely can. You
> can read code aligned by two spaces, right?
Sure, but you can't mix that in the same file
with something else. Indentation and braces have
to be consistent. Other stuff matters far less.
> > We don't need any more bureaucracy.
> >
> > do_this(a,b); (1)
> > do_this(a, b); (2)
> > do_this (a,b);
>
> This looks extremely bad.
>
> > do_this (a, b);
> >
> > I can read them all. I might notice the space in
> > front of the '(', but I might not. Even putting a
> > space in front of the ';' isn't unreadable.
> >
> > People will pass laws until they are choked off,
> > unable to move without being in violation of some
> > silly little thing.
>
> I've seen people "fixing" code from (2) to (1), because they thought I
> prefer (1). (And I definitely don't). So yes, it is important.
Spaces are good for grouping things to increase readability.
So one might do this:
foo(a,b,c,d,e,f);
bar(a+b, a-b); // space needed for readability
baz(a,b, c,d); // suppose a and b logically go together, as do c and d
zzz(a==b && c==d); // common for an "if"
Slapping some arbitrary rule on top of this would
prohibit attempts to make things more readable.
Consider alignment between various lines when
calling similar functions:
foo(a, b+c, *q, *p);
bar(a, b+c, another, *q, *p);
baz(a, b, another, *q );
Sometimes it helps to see things neatly lined up
like that. Sometimes not, of course. The author
needs freedom to lay things out nicely when it matters,
while not concerning himself with trivial spacing
differences when it doesn't matter.
next prev parent reply other threads:[~2004-08-17 19:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-17 11:51 Coding style: do_this(a,b) vs. do_this(a, b) Albert Cahalan
2004-08-17 16:07 ` Alexander Nyberg
2004-08-17 16:40 ` Pavel Machek
2004-08-17 17:07 ` Albert Cahalan [this message]
2004-08-17 20:00 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2004-08-17 10:38 Pavel Machek
2004-08-17 21:09 ` Fao, Sean
2004-08-17 21:14 ` Pavel Machek
2004-08-17 21:59 ` Frank van Maarseveen
2004-08-17 22:29 ` Andrew Morton
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=1092762468.5759.1524.camel@cube \
--to=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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