[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <524404A9.3030602@ahsoftware.de>
Date: Thu, 26 Sep 2013 11:55:53 +0200
From: Alexander Holler <holler@...oftware.de>
To: Julia Lawall <julia.lawall@...6.fr>
CC: Al Viro <viro@...IV.linux.org.uk>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Peter Senna Tschudin <peter.senna@...il.com>,
Dan Carpenter <dan.carpenter@...cle.com>,
kernel-janitors@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: checkpatch guide for newbies
Am 26.09.2013 07:53, schrieb Julia Lawall:
>> 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
It just was the first long function name I came about. And sometimes a
bit background information helps a lot. So without knowing anything else
about that function, I assume the monotonic time is meant and the author
didn't want to add _time_ to the name because it already is long. In
case of the wtom I would think it's from a second author and I still
have no clue what it might be. Maybe I'm missing some backgroud
information here too and should actually read the description of the
function, if there is any. ;)
> 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.
I didn't want do suggest getting rid of (necessary or helpful) comments.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists