kernel-janitors.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: 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 04:21:43 +0000	[thread overview]
Message-ID: <5243B657.7070106@ahsoftware.de> (raw)
In-Reply-To: <20130926034828.GJ13318@ZenIV.linux.org.uk>

Am 26.09.2013 05:48, schrieb Al Viro:
> On Thu, Sep 26, 2013 at 05:27:15AM +0200, Alexander Holler wrote:
>
>> 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);
>
> Charming...  Now, try to tell one such name from another, when the
> only difference is buried in the middle of long phrase.  And yes,
> I've seen mistakes clearly of that origin.  Made them myself, actually.
>

Nothing is perfect. But the source of the discussion was that I don't 
aggree that limiting the line length makes code more simple.

E.g. In your previous example they could have used some verbose name for 
"flag" without having to cross an obvious non-existing limit. Such the 
author might have seen the "problem" early himself. And I think we all 
do sometimes write silly code, even when we should know it better.

E.g. my first version of something like your example don't have 
necessarily been better as I'm usually first write something down which 
I believe should work, not taking care about anything but functionality. 
Then I take a break and have a second look in such a way like you just 
have exercised it. And I think most people are unable to write perfect 
code right out of their fingers. Of course, I think I got much better in 
avoiding deep nesting right from the beginning, but I'm sure I still 
write sometimes stupid code. And then there are those time constraints 
one just has to withstand, besides the fact that it happens sometimes 
that I just don't won't to have a look at my own code again. (The last 
limit is often reached by endless reviews with comments to remove a 
space here and rename a variable there). Nothing is more annoying than 
rewriting source until it looks like if the commenter has written it.

People do think differently, people see code differently and people 
write code differently and trying to unify that with unnecessary rules 
just annoys almost everyone. I do like it if I can tell who has written 
some code by just looking at it, at least if it is readable and isn't in 
some obvious uglyand hard to read and hard to understand state.

n8,

Alexander Holler


  reply	other threads:[~2013-09-26  4:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23  9:01 checkpatch guide for newbies 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 [this message]
2013-09-26  5:53                     ` Julia Lawall
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=5243B657.7070106@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=bhelgaas@google.com \
    --cc=dan.carpenter@oracle.com \
    --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;
as well as URLs for NNTP newsgroup(s).