From: Julia Lawall <julia.lawall@lip6.fr>
To: Alexander Holler <holler@ahsoftware.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Bjorn Helgaas <bhelgaas@google.com>,
Peter Senna Tschudin <peter.senna@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
kernel-janitors@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: checkpatch guide for newbies
Date: Thu, 26 Sep 2013 07:53:40 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.02.1309260749580.1984@localhost6.localdomain6> (raw)
In-Reply-To: <5243A993.9070108@ahsoftware.de>
On Thu, 26 Sep 2013, Alexander Holler wrote:
> Am 26.09.2013 05:04, schrieb Al Viro:
> > On Thu, Sep 26, 2013 at 04:57:32AM +0200, Alexander Holler wrote:
> > > Am 26.09.2013 04:52, schrieb Alexander Holler:
> > >
> > > > I'm aware of people which do nest 8 levels deep just to avoid a return,
> > > > break or goto.
> > > >
> > > > But trying to limit that by limiting the line length is like ...
> > > > (choose your own own misguided comparison, it's too late for me I
> > > > currently only meorize some of those which don't make sense in english)
> > >
> > > But I'm still able to offer a solution: ;)
> > >
> > > limit the number of tabs, not the line length (at least not to 80).
> >
> > With that limited (and it's visually harder to keep track of), what's
> > the problem with 80-column limit on line length? Just how long do
> > you want those "descriptive names" to be?
>
> Oh, personally I don't have any limit there. ;) I like descriptive function
> and variable names whenever they make sense. And often they make comments
> uneccessary and therefor prevent errors because those descriptive names are
> visible whenever the function or variable is used, and comments usually appear
> only once and get forgotten when scrolled out of the screen.
>
> But just take a function like
>
> void get_xtime_and_monotonic_and_sleep_offset(struct timespec *xtim,
> struct timespec *wtom, struct timespec
> *sleep);
>
> I like such function names ;) (ok I wouldn't have use those and), but it's
> hard to press this into 80 characters, especially when the arguments should
> have some meaning too (e.g. what does wtom stand for?)
>
> If you use that somewhere you get
>
> get_xtime_and_monotonic_and_sleep_offset(a, b, c)
>
> using silly names and that already is a 58 characters long. So only 22 are
> left to distribute over 3 variable names. And now think what happens if that
> wouldn't be a void function.
Personally, I prefer to use my screen real estate for multiple 80-column
windows, so I can see different parts of the code at once. Anything that
goes over 80 columns is very hard to read.
Perhaps it is a bad example, but I don't even find this very long name
very understandable. Monotonic is an adjective and xtime and sleep are
nouns, so I don't understand how it all fits together. Maybe cramming a
lot of information into a variable name is not always so successful...
Actually, I really appreciate comments on functions, that explain the
purpose of the function, and the constraints on its usage.
julia
next prev parent reply other threads:[~2013-09-26 5:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 9:01 Dan Carpenter
2013-09-23 12:46 ` Peter Senna Tschudin
2013-09-23 13:29 ` Dan Carpenter
2013-09-23 14:04 ` Geert Uytterhoeven
2013-09-23 18:06 ` Joe Perches
2013-09-23 20:17 ` Joe Perches
2013-09-23 18:35 ` bojan prtvar
2013-09-24 16:36 ` Bjorn Helgaas
2013-09-24 17:26 ` Alexander Holler
2013-09-24 17:43 ` Alexander Holler
2013-09-24 18:50 ` Alexander Holler
2013-09-24 19:29 ` Peter Senna Tschudin
2013-09-24 19:59 ` Dan Carpenter
2013-09-24 20:13 ` Bjorn Helgaas
2013-09-24 22:10 ` Alexander Holler
2013-09-26 2:11 ` Al Viro
2013-09-26 2:52 ` Alexander Holler
2013-09-26 2:57 ` Alexander Holler
2013-09-26 3:04 ` Al Viro
2013-09-26 3:27 ` Alexander Holler
2013-09-26 3:48 ` Al Viro
2013-09-26 4:21 ` Alexander Holler
2013-09-26 5:53 ` Julia Lawall [this message]
2013-09-26 9:55 ` Alexander Holler
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=alpine.DEB.2.02.1309260749580.1984@localhost6.localdomain6 \
--to=julia.lawall@lip6.fr \
--cc=bhelgaas@google.com \
--cc=dan.carpenter@oracle.com \
--cc=holler@ahsoftware.de \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.senna@gmail.com \
--cc=viro@ZenIV.linux.org.uk \
/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
all inboxes | Powered by JetHome®