From: "Angelo Dell'Aera" <buffer@antifork.org>
To: Giuliano Pochini <pochini@shiny.it>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
Michael Frank <mhf@linuxmail.org>
Subject: Re: PATCH, RFC: 2.6 Documentation/Codingstyle
Date: Fri, 13 Feb 2004 15:35:42 +0100 [thread overview]
Message-ID: <20040213153542.29686f0f.buffer@antifork.org> (raw)
In-Reply-To: <XFMail.20040213145513.pochini@shiny.it>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 13 Feb 2004 14:55:13 +0100 (CET)
Giuliano Pochini <pochini@shiny.it> wrote:
>> The 80 here has a pedagogical and a practical purpose.
>> The practical one is that it makes sure that everybody can read the source.
>> The pedagogical is to invite you to arrange the code in a different way
>> if you are nesting too deeply or your expressions are too complicated.
>Deeply nested doesn't mean unreadable or badly structured.
I think you're really wrong since "deeply nested" means exactly "unreadable
and badly structured" and you could easily realize it by simply spending ~10
hours per day coding and/or taking a look at the code written by someone
which is not you. A simple use of inline functions and a previous thinking
about what you're going to write could easily solve all problems.
>1 tab in the function, 1tab a switch, 1 if, 1 for, 1 if and you have already
>lost half of the available space. It's not difficult to find lines compressed
>towards the 79th column in the kernel sources. I propose to change "hard limit"
>to "soft limit" to avoid things like this:
>
> rc=idefloppy_begin_format(drive, inode,
> file,
> (int *)arg);
No one is saying this line of code is the best one could imagine... have you
ever thought that maybe anything "floating around" that code line could be
written in a not-well structured way?
>IMO we should try to keep function calls on the same line. btw it's
>only a matter of taste and the compiler accepts ugly code too :))
A compiler should do it, a maintainer IMHO should not for a really simple
reason: readability (which in most cases means maintainability too).
>> There is also ergonomics. There is a reason newspapers do not print
>> text across the full width of the page - it would be very difficult
>> to read.
>Code has only one instruction per line.
Not a good point.
Regards.
- --
Angelo Dell'Aera 'buffer'
Antifork Research, Inc. http://buffer.antifork.org
PGP information in e-mail header
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFALOC+pONIzxnBXKIRApWFAJ9JjvwcnfgPz1V5bvfwzjE2Xb7c5wCfWdOH
s9fGQvTBV3iEaZQdy8tp8nQ=
=v4FT
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-02-13 14:35 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 22:15 PATCH, RFC: 2.6 Documentation/Codingstyle Michael Frank
2004-02-12 23:20 ` Tim Bird
2004-02-12 23:46 ` Måns Rullgård
2004-02-13 0:19 ` Tim Hockin
2004-02-12 23:38 ` Randy.Dunlap
2004-02-13 1:50 ` Alex Goddard
2004-02-13 1:52 ` Maciej Zenczykowski
2004-02-13 0:13 ` viro
2004-02-13 1:12 ` J. Bruce Fields
2004-02-13 8:49 ` PATCH, RFC: Version 2 of 2.6 Codingstyle Michael Frank
2004-02-13 9:44 ` Andries Brouwer
2004-02-13 11:24 ` Nikita Danilov
2004-02-16 17:56 ` Ludootje
2004-02-13 22:38 ` Randy.Dunlap
2004-02-13 8:58 ` PATCH, RFC: 2.6 Documentation/Codingstyle Giuliano Pochini
2004-02-13 9:10 ` Andrew Morton
2004-02-13 9:49 ` Michael Frank
2004-02-13 10:09 ` Nick Piggin
2004-02-13 10:50 ` Michael Frank
2004-02-18 7:39 ` Miles Bader
2004-02-13 12:44 ` viro
2004-02-13 9:19 ` David Weinehall
2004-02-13 11:42 ` Andries Brouwer
2004-02-13 12:13 ` Måns Rullgård
2004-02-13 12:42 ` Ed Tomlinson
2004-02-13 13:55 ` Giuliano Pochini
2004-02-13 14:35 ` Angelo Dell'Aera [this message]
2004-02-13 15:42 ` Giuliano Pochini
2004-02-13 15:48 ` Valdis.Kletnieks
2004-02-13 16:38 ` Angelo Dell'Aera
2004-02-13 17:03 ` Valdis.Kletnieks
2004-02-13 16:18 ` viro
2004-02-14 0:38 ` Kevin O'Connor
2004-02-14 0:56 ` Valdis.Kletnieks
2004-02-14 1:44 ` PATCH, RFC: Version 3 of 2.6 Codingstyle Michael Frank
2004-02-14 3:44 ` Dmitry Torokhov
2004-02-15 10:09 ` Jamie Lokier
2004-02-14 20:44 ` PATCH, RFC: Version 4 " Michael Frank
2004-02-14 21:27 ` viro
2004-02-16 3:47 ` PATCH, RFC: Version 5 " Michael Frank
[not found] <fa.fbh88ra.kn8094@ifi.uio.no>
2004-02-13 6:41 ` PATCH, RFC: 2.6 Documentation/Codingstyle Junio C Hamano
2004-02-13 7:18 ` vda
2004-02-13 12:37 ` Maciej Zenczykowski
2004-02-13 13:57 ` vda
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=20040213153542.29686f0f.buffer@antifork.org \
--to=buffer@antifork.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhf@linuxmail.org \
--cc=pochini@shiny.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.