Coding style - a non-issue

1235 views
Skip to first unread message

Peter Waltenberg

unread,
Nov 28, 2001, 6:38:05 PM11/28/01
to linux-...@vger.kernel.org
The problem was solved years ago.

"man indent"

Someone who cares, come up with an indentrc for the kernel code, and get it
into Documentation/CodingStyle
If the maintainers run all new code through indent with that indentrc
before checkin, the problem goes away.
The only one who'll incur any pain then is a code submitter who didn't
follow the rules. (Exactly the person we want to be in pain ;)).


Then we can all get on with doing useful things.

Cheers
Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

unread,
Nov 28, 2001, 6:43:27 PM11/28/01
to Peter Waltenberg, linux-...@vger.kernel.org
> The problem was solved years ago.
>
> "man indent"
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle

The problem was solved years ago.

scripts/Lindent

Russell King

unread,
Nov 28, 2001, 6:48:40 PM11/28/01
to Peter Waltenberg, linux-...@vger.kernel.org
On Thu, Nov 29, 2001 at 09:29:26AM +1000, Peter Waltenberg wrote:
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

See: linux/scripts/Lindent

--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

Robert Love

unread,
Nov 28, 2001, 6:52:58 PM11/28/01
to Peter Waltenberg, linux-...@vger.kernel.org
On Wed, 2001-11-28 at 18:29, Peter Waltenberg wrote:

> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

See scripts/lindent in your source tree ... does just this.

Robert Love

Alexander Viro

unread,
Nov 28, 2001, 7:19:58 PM11/28/01
to Peter Waltenberg, linux-...@vger.kernel.org

On Thu, 29 Nov 2001, Peter Waltenberg wrote:

> The problem was solved years ago.
>
> "man indent"
>
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).

indent does _not_ solve the problem of:
* buggers who think that MyVariableIsBiggerThanYourVariable is a
good name
* buggers who define a function with 42 arguments and body being
return (foo == bar) ? TRUE : FALSE;
* buggers who add 1001st broken implementation of memcmp(), call it
FooTurdCompare and prepend it with 20x80 block comment.
* buggers who use typedefs like WORD, DWORD, BYTE, IMANIDIOTSHOOTME
and other crap from the same source (OK, they don't write the last one
explicitly - not that it wasn't obvious from the rest of their, ahem, code).
* buggers who use Hungarian notation for no good reason and come up
with structure fields that sound like street names from R'Lyeh
* buggers who introduce wrappers for standard kernel stuff - like,
say it, typedef int Int32; and sprinkle their crap with per-architecture
ifdefs.
* buggers who think that cpp is Just The Thing and produce turds that
would make srb cringe in disgust.

Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
wankers (both individual and coprorat ones) responsible, their code and
commentary on said code...

Larry McVoy

unread,
Nov 28, 2001, 7:24:40 PM11/28/01
to Alexander Viro, Peter Waltenberg, linux-...@vger.kernel.org
> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...

Please, please, please, I'm begging you, please do this. It's the only way
people learn quickly. Being nice is great, but nothing works faster than
a cold shower of public humiliation :-)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Davide Libenzi

unread,
Nov 28, 2001, 7:50:21 PM11/28/01
to Larry McVoy, Alexander Viro, lkml
On Wed, 28 Nov 2001, Larry McVoy wrote:

> > Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> > wankers (both individual and coprorat ones) responsible, their code and
> > commentary on said code...
>
> Please, please, please, I'm begging you, please do this. It's the only way
> people learn quickly. Being nice is great, but nothing works faster than
> a cold shower of public humiliation :-)

Well, I don't know about "Hall of Shame" but having an "Hall of Flame"
without you two guys is like going at the OktoberFest being abstemious :)

- Davide

David S. Miller

unread,
Nov 28, 2001, 7:53:15 PM11/28/01
to vi...@math.psu.edu, pwa...@au1.ibm.com, linux-...@vger.kernel.org
From: Alexander Viro <vi...@math.psu.edu>
Date: Wed, 28 Nov 2001 19:17:42 -0500 (EST)


indent does _not_ solve the problem of:

Al, I think you just described the Intel e100 driver.
:-)

Petko Manolov

unread,
Nov 28, 2001, 8:12:08 PM11/28/01
to Alexander Viro, Peter Waltenberg, linux-...@vger.kernel.org
Alexander Viro wrote:

>
>>Someone who cares, come up with an indentrc for the kernel code, and get it
>>into Documentation/CodingStyle

...

> indent does _not_ solve the problem of:

...


I quite liked it, applies perfectly for some people i know... :-)

Anyway, in Lindent you'll see "-psl" (--procname-start-lines) option
which contradict with what is written in CodingStyle i.e:

int my_proc(void)
{
...
}

which I personally prefer.


Petko

Matthias Andree

unread,
Nov 28, 2001, 8:58:53 PM11/28/01
to linux-...@vger.kernel.org
On Wed, 28 Nov 2001, Alexander Viro wrote:

> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> wankers (both individual and coprorat ones) responsible, their code and
> commentary on said code...

Oh, can I vote for someone spoiling outside the Kernel? I have a
candidate for that one.

Seriously, don't waste your *p_time on that except people resist any
hints to CodingStyleIsForLameAssHackersIWantMyEDIT.COM for an extended
amount of *p_time.

--
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin

Larry McVoy

unread,
Nov 30, 2001, 10:28:02 AM11/30/01
to h...@intermeta.de, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 10:00:00AM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <l...@bitmover.com> writes:
>
> >> Al, -><- close to setting up a Linux Kernel Hall of Shame - one with names of
> >> wankers (both individual and coprorat ones) responsible, their code and
> >> commentary on said code...
>
> >Please, please, please, I'm begging you, please do this. It's the only way
> >people learn quickly. Being nice is great, but nothing works faster than
> >a cold shower of public humiliation :-)
>
> Cool. I can really see it. "foo inc." releases a GPL driver for Linux
> and gets publically humiliated in the "linux source code hall of
> shame". Perfect. I can hear the laughter from Redmond over here (and
> it is 12000km away).
>
> Sigh, sometimes, sometimes, I _really_ understand the BSD folks when
> they call the Linux community "a bunch of unkempt nerds that need to
> get a life".

Perhaps it would be illuminating to know that I was BSD hacker,
and that I learned the value of this particular technique from
Sun's kernel group, who once upon a time were the best BSD group
on the planet. It might also be illuminating to consider that
this technique of getting people to listen is still in use at
Sun to this day.

Perhaps Sun's professionalism is not what you'd like to see here.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Henning Schmiedehausen

unread,
Nov 30, 2001, 11:40:50 AM11/30/01
to Larry McVoy, linux-...@vger.kernel.org
On Fri, 2001-11-30 at 16:26, Larry McVoy wrote:

Hi,

> Perhaps it would be illuminating to know that I was BSD hacker,
> and that I learned the value of this particular technique from

I know. You tell us this again and again. Please stop patronizing.

> Sun's kernel group, who once upon a time were the best BSD group
> on the planet. It might also be illuminating to consider that
> this technique of getting people to listen is still in use at
> Sun to this day.

It might be enlightening to you that a closed users group of SUN coders
is not compareable to a worldwide distributed environment of thousands
of people and companies.

>
> Perhaps Sun's professionalism is not what you'd like to see here.#

You tell me, that SUN treated _CUSTOMERS_ and companies that wanted to
support SunOS 4.1.x like that? If yes, then I definitely know why they
went SysV. Surely noone wanted BSD any longer.

I would consider the internal development groups in SUN that treated
each other like this also "in need of a change". :-)

Regards
Henning

--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20

Jeff Garzik

unread,
Nov 30, 2001, 11:49:48 AM11/30/01
to Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
The security community has shown us time and again that public shaming
is often the only way to motivate vendors into fixing security
problems. Yes, even BSD security guys do this :)

A "Top 10 ugliest Linux kernel drivers" list would probably provide
similar motivation.

Jeff


--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

Henning Schmiedehausen

unread,
Nov 30, 2001, 12:16:59 PM11/30/01
to Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org
On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:

Hi,

> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)
>
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.

A security issue is an universal accepted problem that most of the time
has a reason and a solution.

Coding style, however, is a very personal thing that start with "shall
we use TABs or not? (Jakarta: No. Linux: Yes ...) and goes on to "Is a
preprocessor macro a good thing or not" until variable names (Al Viro:
Names with more than five letters suck. :-) Java: Non-selfdescriptive
names suck. Microsoft: Non-hungarian names suck) and so on.

And you really want to judge code just because someone likes to wrap
code in preprocessor macros or use UPPERCASE variable names?

Come on. That's a _fundamental_ different issue than dipping vendors in
their own shit if they messed up and their box/program has a security
issue. Code that you consider ugly as hell may be seen as "easily
understandable and maintainable" by the author. If it works and has no
bugs, so what? Just because it is hard for you and me to understand (cf.
"mindboggling unwind routines in the NTFS" (I thing Jeff Merkey stated
it like this). It still seems to work quite well.

Are you willing to judge "ugliness" of kernel drivers? What is ugly? Are
Donald Beckers' drivers ugly just because they use (at least on 2.2)
their own pci helper library? Is the aic7xxx driver ugly because it
needs libdb ? Or is ugly defined as "Larry and Al don't like them"? :-)

Flaming about coding style is about as pointless as flaming someone
because he supports another sports team. There is no universal accepted
coding style. Not even in C.

Regards
Henning


--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20

-

Alan Cox

unread,
Nov 30, 2001, 12:24:43 PM11/30/01
to Henning Schmiedehausen, Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org
> Flaming about coding style is about as pointless as flaming someone
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.

The kernel has an accepted coding style, both the documented and the
tradition part of it. Using that makes life a lot lot easier for maintaining
the code. Enforcing it there is a good idea, except for special cases
(headers shared with NT has been one example of that).

There are also some nice tools around that will do the first stage import of
a Hungarian NT'ese driver and linuxise it.

Alan

Larry McVoy

unread,
Nov 30, 2001, 12:29:10 PM11/30/01
to Henning Schmiedehausen, Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 06:15:28PM +0100, Henning Schmiedehausen wrote:
> On Fri, 2001-11-30 at 17:47, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems. Yes, even BSD security guys do this :)
> >
> > A "Top 10 ugliest Linux kernel drivers" list would probably provide
> > similar motivation.
>
> A security issue is an universal accepted problem that most of the time
> has a reason and a solution.
>
> And you really want to judge code just because someone likes to wrap
> code in preprocessor macros or use UPPERCASE variable names?

Henning, in any long lived source base, coding style is crucial. People
who think that coding style is personal are just wrong. Let's compare,
shall we?

Professional: the coding style at this job looks like XYZ, ok, I will now
make my code look like XYZ.

Amateur: my coding style is better than yours.

I think that if you ask around, you'll find that the pros use a coding
style that isn't theirs, even when writing new code. They have evolved
to use the prevailing style in their environment. I know that's true for
me, my original style was 4 space tabs, curly braces on their own line,
etc. I now code the way Bill Joy codes, fondly known as Bill Joy normal
form.

Anyway, if you think any coding style is better than another, you completely
miss the point. The existing style, whatever it is, is the style you use.
I personally despise the GNU coding style but when I make changes there,
that's what I use because it is their source base, not mine.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Martin Dalecki

unread,
Nov 30, 2001, 12:32:35 PM11/30/01
to Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
Jeff Garzik wrote:
>
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)
>
> A "Top 10 ugliest Linux kernel drivers" list would probably provide
> similar motivation.

Yehh.... However some of the uglinesses results from ignorance
on behalf of the overall kernel maintainers, who don't care
to apply "cosmetic" changes to drivers, just to don't
irritate the oftes so called "maintainer". Two expierences:
ftape and mcd I'm through....

BTW.> ftape (for the pascal emulation) and DAC960
(for the silly ICantReadThisCasing)
are my personal "top ranks" in regard
of the contest for the most ugly code in the kernel...
serial.c is another one for the whole multiport support which
may be used by maybe 0.1% of the Linux users thrown on them all
and some "magic" number silliness as well...

Martin Dalecki

unread,
Nov 30, 2001, 12:35:33 PM11/30/01
to Henning Schmiedehausen, Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org
Henning Schmiedehausen wrote:
> Flaming about coding style is about as pointless as flaming someone
> because he supports another sports team. There is no universal accepted
> coding style. Not even in C.

Bull shit: indent -kr is the way to go. It ever was...

Alan Cox

unread,
Nov 30, 2001, 12:46:43 PM11/30/01
to dal...@evision.ag, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
> irritate the oftes so called "maintainer". Two expierences:
> ftape and mcd I'm through....

I timed the mcd maintainer out and tidied it anyway. I figured since it
wasnt being maintained nobody would scream too loudly - nobody has

> BTW.> ftape (for the pascal emulation) and DAC960

ftape is an awkward one. Really the newer ftape4 wants merging into the
kernel but that should have happened a long time ago

> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...

serial.c is a good example of the "ugly" that actually matters more, as is
floppy.c. Clean well formatted code that is stil opaque.

Russell King

unread,
Nov 30, 2001, 12:53:48 PM11/30/01
to dal...@evision.ag, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 06:20:40PM +0100, Martin Dalecki wrote:
> serial.c is another one for the whole multiport support which
> may be used by maybe 0.1% of the Linux users thrown on them all
> and some "magic" number silliness as well...

Magic number silliness is something that's gone with my replacement
serial drivers. If multiport is such a problem, it can easily be
cleaned up. I'll add that to my to do list for serial stuff.

Thanks.

-

Martin Dalecki

unread,
Nov 30, 2001, 12:55:26 PM11/30/01
to Alan Cox, dal...@evision.ag, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
Alan Cox wrote:
>
> > irritate the oftes so called "maintainer". Two expierences:
> > ftape and mcd I'm through....
>
> I timed the mcd maintainer out and tidied it anyway. I figured since it
> wasnt being maintained nobody would scream too loudly - nobody has

Wenn sorry for the missconception I wanted to insult *you*, my expierenc
in regard to this is even older...

> > BTW.> ftape (for the pascal emulation) and DAC960
>
> ftape is an awkward one. Really the newer ftape4 wants merging into the
> kernel but that should have happened a long time ago

It diverged too much from what's in the kernel since about already 3-4
years.
And I don't think that it's that much better in terms of implementation
style...
Fortunately all those floppy interface iomega streamers are
physically obsolete by now. Plese notice that ftape4 is using a
different storage format, well this is due to the fact that the
ftape inside the kernel wasn't up to the corresponding standard
(QIO-80)...

> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
>
> serial.c is a good example of the "ugly" that actually matters more, as is
> floppy.c. Clean well formatted code that is stil opaque.

floppy.c is indeed one of the best compiler test cases around there.
But personally I would excuse floppy.c a bit becouse it's dealing with
a really awkward controller interface ;-).
serial.c should be hooked at the misc char device interface sooner or
later.
But somehow this never happened becouse nobody dared to care enough.

Henning Schmiedehausen

unread,
Nov 30, 2001, 12:56:23 PM11/30/01
to Larry McVoy, Jeff Garzik, linux-...@vger.kernel.org
On Fri, 2001-11-30 at 18:27, Larry McVoy wrote:

Larry

> I think that if you ask around, you'll find that the pros use a coding
> style that isn't theirs, even when writing new code. They have evolved
> to use the prevailing style in their environment. I know that's true for
> me, my original style was 4 space tabs, curly braces on their own line,
> etc. I now code the way Bill Joy codes, fondly known as Bill Joy normal
> form.

I don't have to ask around. You may want to know that I work in this
industry for about 15 years and write commercial code (that is "code
that ships") since about that time (and I don't run around telling
everybody each and every time about it and what I've already done). I've
written code in a good two dozen languages (including things that really
deserve to die like Comal) and I've worked in projects from "one man
show" to "lots of people in Elbonia also work on this". So, please,
please, Larry, _STOP THE FUCK PATRONIZING OTHERS_. Actually, I try to
consider myself a "pro" in some languages and a bloody amateur in others
(like Lisp or Python). That is "pro" as in "pays his bills with writing
software".

>
> Anyway, if you think any coding style is better than another, you completely
> miss the point. The existing style, whatever it is, is the style you use.
> I personally despise the GNU coding style but when I make changes there,
> that's what I use because it is their source base, not mine.

We're in violent agreement here. Unfortunatly we do not agree whether it
is good to force a driver writer (which is, IMHO, most of the time a
well defined entity of one, maybe two or three source code files that
uses a well established (though sometimes changing) API to talk to the
kernel) to convert his style to the linux kernel ("our style is better
than yours, you must convert") or allow him to continue working (and
maintaining) his driver in the kernel tree in his own style. Even if his
variable names contain Uppercase letters.

The question now is, what is "amateur behaviour": Forcing this driver
writer to change or to tolerate his style in his driver? We're still
talking about a driver, not about the VM subsystem or the networking
core.

And will "putting up a list of the ten most ugly drivers with author
names" really persuade this author to change? Or simply to drop out and
write a driver for an OS that may be more tolerant?

That the core components of a large software project must adhere to a
style guide (and the Linux style guide is pretty good, because it is
_SHORT_), there is no disagreement between you and me.

Regards
Henning



--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20

-

Alexander Viro

unread,
Nov 30, 2001, 12:58:01 PM11/30/01
to Henning Schmiedehausen, Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org

On 30 Nov 2001, Henning Schmiedehausen wrote:

> issue. Code that you consider ugly as hell may be seen as "easily
> understandable and maintainable" by the author. If it works and has no
> bugs, so what? Just because it is hard for you and me to understand (cf.

... it goes without peer review for years. And that means bugs.

Fact of life: we all suck at reviewing our own code. You, me, Ken Thompson,
anybody - we tend to overlook bugs in the code we'd written. Depending on
the skill we can compensate - there are technics for that, but it doesn't
change the fact that review by clued people who didn't write the thing
tends to show bugs we'd missed for years.

If you really don't know that by your own experience - you don't _have_
experience. There is a damn good reason for uniform style within a
project: peer review helps. I've lost the count of bugs in the drivers
that I'd found just grepping the tree. Even on that level review catches
tons of bugs. And I have no reason to doubt that authors of respective
drivers would fix them as soon as they'd see said bugs.

"It's my code and I don't care if nobody else can read it" is an immediate
firing offense in any sane place. It may be OK in academentia, but in the
real life it's simply unacceptable.

It's all nice and dandy to shed tears for poor, abused, well-meaning company
that had made everyone happy by correct but unreadable code and now gets
humiliated by mean ingrates. Nice image, but in reality the picture is
quite different. Code _is_ buggy. That much is a given, regardless of
the origin of that code. The only question is how soon are these bugs
fixed. And that directly depends on the amount of efforts required to
read through that code.

Sigh... Ironic that _you_ recommend somebody to grow up - I would expect
the level of naivety you'd demonstrated from a CS grad who'd never worked
on anything beyond his toy project. Not from somebody adult.

Martin Dalecki

unread,
Nov 30, 2001, 1:01:03 PM11/30/01
to Russell King, dal...@evision.ag, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
Russell King wrote:
>
> On Fri, Nov 30, 2001 at 06:20:40PM +0100, Martin Dalecki wrote:
> > serial.c is another one for the whole multiport support which
> > may be used by maybe 0.1% of the Linux users thrown on them all
> > and some "magic" number silliness as well...
>
> Magic number silliness is something that's gone with my replacement
> serial drivers. If multiport is such a problem, it can easily be
> cleaned up. I'll add that to my to do list for serial stuff.

Well sombeody really cares apparently! Thank's. Any pointers
where to ahve a look at it? BTW> Did you consider ther misc device
idea? (Hooking serial at to the misc device stuff).

antirez

unread,
Nov 30, 2001, 1:03:47 PM11/30/01
to Jeff Garzik, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 11:47:28AM -0500, Jeff Garzik wrote:
> The security community has shown us time and again that public shaming
> is often the only way to motivate vendors into fixing security
> problems. Yes, even BSD security guys do this :)

It's a bit different. Usually the security community uses it
when there isn't a way to fix the code (i.e. non-free code)
or when the maintaner of the code refused to fix the issue.
Also to "expose" the security problem isn't the same as
to flame.

While not a good idea, something like a long name
for a local var isn't a big problem like a completly
broken software with huge security holes used by milions of people
every day.

The quality of the code should be ensured in a different
way. If there is a standard coding-style you should either:

1) refuse to include broken code before the programmer fix it
2) fix it yourself before the inclusion

Flames aren't a good solution imho.

--
Salvatore Sanfilippo <ant...@invece.org>
http://www.kyuzz.org/antirez
finger ant...@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Russell King

unread,
Nov 30, 2001, 1:04:22 PM11/30/01
to dal...@evision.ag, Alan Cox, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 06:42:17PM +0100, Martin Dalecki wrote:
> serial.c should be hooked at the misc char device interface sooner or
> later.

Please explain. Especially contentrate on justifing why serial interfaces
aren't a tty device.

Thanks.

-

Russell King

unread,
Nov 30, 2001, 1:05:42 PM11/30/01
to dal...@evision.ag, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 06:49:01PM +0100, Martin Dalecki wrote:
> Well sombeody really cares apparently! Thank's.

Currently its a restructuring of serial.c to allow different uart type
ports to be driven without duplicating serial.c many times over. (the
generic_serial didn't hack it either).

> Any pointers where to ahve a look at it?

I should probably put this on a web page somewhere 8)

:pserver:c...@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
(no password)

> BTW> Did you consider ther misc device idea? (Hooking serial at to the
> misc device stuff).

I just caught that comment - I'll await your reply.

-

Martin Dalecki

unread,
Nov 30, 2001, 1:07:53 PM11/30/01
to Russell King, dal...@evision.ag, Alan Cox, Jeff Garzik, Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
Russell King wrote:
>
> On Fri, Nov 30, 2001 at 06:42:17PM +0100, Martin Dalecki wrote:
> > serial.c should be hooked at the misc char device interface sooner or
> > later.
>
> Please explain. Especially contentrate on justifing why serial interfaces
> aren't a tty device.

No problem ;-).

There is the hardware: in esp. the serial controller itself - this
belongs
to misc, becouse a mouse for example doesn't have to interpret any tty
stuff
This animal belongs to the same cage as the PS/2 variant of it.
And then there is one abstraction level above it: the tty interface -
this belongs to a line discipline.

We have this split anyway already there /dev/ttyS0 and /dev/cua0 somehow
emulated on one level.

Understood?

Larry McVoy

unread,
Nov 30, 2001, 1:10:15 PM11/30/01
to Henning Schmiedehausen, Larry McVoy, Jeff Garzik, linux-...@vger.kernel.org
Henning, perhaps you can explain to me how the following isn't a

"I don't do XYZ"

"XYZ"

statement?

On Fri, Nov 30, 2001 at 06:53:05PM +0100, Henning Schmiedehausen wrote:
> You may want to know that I work in this
> industry for about 15 years and write commercial code (that is "code
> that ships") since about that time (and I don't run around telling
> everybody each and every time about it and what I've already done).

That would be the "I don't do XYZ..."

> I've
> written code in a good two dozen languages (including things that really
> deserve to die like Comal) and I've worked in projects from "one man
> show" to "lots of people in Elbonia also work on this".

And this would be the "XYZ".

If you are going to yell at people for a particular behaviour, it's really
more effective if you don't show that behaviour in the midst of your yelling,
wouldn't you agree? Just a friendly thought.

> So, please, please, Larry, _STOP THE FUCK PATRONIZING OTHERS_.

It would appear that you find everything I say patronizing, regardless of
what it is or how it is said. I'm sorry about that, but I'm not going
to change how I speak to suit you. Yell all you want. I'd suggest
that if you find my emails offensive, you add me to your kill file.

> The question now is, what is "amateur behaviour": Forcing this driver
> writer to change or to tolerate his style in his driver? We're still
> talking about a driver, not about the VM subsystem or the networking
> core.

Your approach to this whole topic is a good example of why I run my own
company and I have absolute authority to fire people at will. If you
worked here and you persisted with this approach, you would be fired,
without question. I don't know how to say it more clearly, I don't
say it lightly, hiring someone, training them, all of that is a huge
investment. One which I would discard if you couldn't fit in. Coding
style is part of fitting in, it isn't optional in any code I pay for.

You may have a different view, that's cool, you're entitled. But realize
that any professional software organization is unlikely to agree with you.
For whatever that is worth.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Henning Schmiedehausen

unread,
Nov 30, 2001, 1:10:33 PM11/30/01
to Alexander Viro, Jeff Garzik, Larry McVoy, linux-...@vger.kernel.org
On Fri, 2001-11-30 at 18:55, Alexander Viro wrote:

Hi,

> On 30 Nov 2001, Henning Schmiedehausen wrote:
>
> > issue. Code that you consider ugly as hell may be seen as "easily
> > understandable and maintainable" by the author. If it works and has no
> > bugs, so what? Just because it is hard for you and me to understand (cf.
>
> ... it goes without peer review for years. And that means bugs.

That's right. And I didn't say, that _this is a good thing_. The
question was (and is IMHO), "do we put such code into a "hall of driver
writer shame" or do we either just reject the code from the kernel tree
or do we help "the poor misunderstood vendor" to convert.

Simply flaming them down will definitely not help. As someone with your
experience should know, too.

> Sigh... Ironic that _you_ recommend somebody to grow up - I would expect
> the level of naivety you'd demonstrated from a CS grad who'd never worked
> on anything beyond his toy project. Not from somebody adult.

You're welcome.

I'm willing to give you a bet: You put up such a "hall of shame" and we
will see what comes first:

a) media echo that "linux core developers start insulting code
committers"

or

b) vendors start cleaning up their code.

Regards
Henning


--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20

-

Alexander Viro

unread,
Nov 30, 2001, 1:11:54 PM11/30/01
to Daniel Phillips, Larry McVoy, Henning Schmiedehausen, Jeff Garzik, linux-...@vger.kernel.org

On Fri, 30 Nov 2001, Daniel Phillips wrote:

> On the other hand, the idea of a coding style hall of shame - publicly
> humiliating kernel contributers - is immature and just plain silly. It's
> good to have a giggle thinking about it, but that's where it should stop.

Damnit, Daniel, are you deliberately trying to tempt me into doing that?

Larry McVoy

unread,
Nov 30, 2001, 1:14:55 PM11/30/01
to Daniel Phillips, Larry McVoy, Henning Schmiedehausen, Jeff Garzik, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> On the other hand, the idea of a coding style hall of shame - publicly
> humiliating kernel contributers - is immature and just plain silly. It's
> good to have a giggle thinking about it, but that's where it should stop.

If you've got a more effective way of getting people to do the right thing,
lets hear it. Remember, the goal is to protect the source base, not your,
my, or another's ego.

I used to think Sun's approach was pretty brutal, and I still do actually.
But I haven't found anything else which works as well. I don't use that
technique at BitMover, instead I rewrite code that I find offensive. That's
less annoying to the engineers but it is also a lot more costly in terms of
my time. Since we're a small company, I can keep up. When we double in
size, I won't be able to do so and I suspect we'll revert to the Sun way.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Paul G. Allen

unread,
Nov 30, 2001, 1:18:32 PM11/30/01
to Linux kernel developer's mailing list, kplug...@kernel-panic.org, kplug...@kernel-panic.org
Peter Waltenberg wrote:
>
> The problem was solved years ago.
>
> "man indent"

>
> Someone who cares, come up with an indentrc for the kernel code, and get it
> into Documentation/CodingStyle
> If the maintainers run all new code through indent with that indentrc
> before checkin, the problem goes away.
> The only one who'll incur any pain then is a code submitter who didn't
> follow the rules. (Exactly the person we want to be in pain ;)).
>
> Then we can all get on with doing useful things.
>

IMEO, there is but one source as reference for coding style: A book by
the name of "Code Complete". (Sorry, I can't remember the author and I
no longer have a copy. Maybe my Brother will chime in here and fill in
the blanks since he still has his copy.)

Outside of that, every place I have worked as a programmer, with a team
of programmers, had a style that was adhered to almost religiously. In
many cases the style closely followed "Code Complete". In the case of
the kernel, as Alan and others have mentioned, there IS a Linux kernel
coding style.

In 99% of the Linux code I have seen, the style does indeed "suck". Why?
Consider a new coder coming in for any given task. S/he knows nothing
about the kernel and needs to get up to speed quickly. S/he starts
browsing the source - the ONLY definitive explanation of what it does
and how it works - and finds:

- Single letter variable names that aren't simple loop counters and
must ask "What the h*** are these for?"
- No function/file comment headers explaining what the purpose of the
function/file is.
- Very few comments at all, which is not necessarily bad except...
- The code is not self documenting and without comments it takes an
hour to figure out what function Foo() does.
- Opening curly braces at the end of a the first line of a large code
block making it extremely difficult to find where the code block begins
or ends.
- Short variable/function names that someone thinks is descriptive but
really isn't.
- Inconsistent coding style from one file to the next.
- Other problems.

After all, the kernel must be maintained by a number of people and those
people will come and go. The only real way to keep bugs at a minimum,
efficiency at a maximum, and the learning curve for new coders
acceptable is consistent coding style and code that is easily
maintained. The things I note above are not a means to that end. Sure,
maybe Bob, the designer and coder of bobsdriver.o knows the code inside
and out without need of a single comment or descriptive
function/variable name, but what happens when Bob can no longer maintain
it? It's 10,000 lines of code, the kernel is useless without it, it
broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
having a hell of a time figuring out what the damn thing does.

An extreme case? Maybe, but how many times does someone come in to
development and have to spend more hours than necessary trying to figure
out how things work (or are supposed to work) instead of actually
writing useful code?

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Dana Lacoste

unread,
Nov 30, 2001, 1:21:54 PM11/30/01
to Larry McVoy, Henning Schmiedehausen, Jeff Garzik, linux-...@vger.kernel.org
Any chance that you guys could calm down a bit?

I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....

> Henning, perhaps you can explain to me how the following isn't a
>
> "I don't do XYZ"
>
> "XYZ"
>
> statement?

This one I understood though :
Al made a personal attack. He defended against the attack,
and preluded his defence with a disclaimer.

This issue has gone beyond productivity to personal name calling
and spurious defence. Can we all just move on a bit maybe?

Thanks

--
Dana Lacoste - Linux Developer
Peregrine Systems - Ottawa, Canada

Paul G. Allen

unread,
Nov 30, 2001, 1:24:30 PM11/30/01
to Linux kernel developer's mailing list
antirez wrote:
>
> On Fri, Nov 30, 2001 at 11:47:28AM -0500, Jeff Garzik wrote:
> > The security community has shown us time and again that public shaming
> > is often the only way to motivate vendors into fixing security
> > problems. Yes, even BSD security guys do this :)
>
> It's a bit different. Usually the security community uses it
> when there isn't a way to fix the code (i.e. non-free code)
> or when the maintaner of the code refused to fix the issue.
> Also to "expose" the security problem isn't the same as
> to flame.
>
> While not a good idea, something like a long name
> for a local var isn't a big problem like a completly
> broken software with huge security holes used by milions of people
> every day.
>

A variable/function name should ALWAYS be descriptive of the
variable/function purpose. If it takes a long name, so be it. At least
the next guy looking at it will know what it is for.

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

John H. Robinson, IV

unread,
Nov 30, 2001, 1:31:44 PM11/30/01
to Paul G. Allen, Linux kernel developer's mailing list, kplug...@kernel-panic.org, kplug...@kernel-panic.org
On Fri, Nov 30, 2001 at 10:15:41AM -0800, Paul G. Allen wrote:
>
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)

Code Complete: A Practical Handbook of Software Construction.
Redmond, Wa.: Microsoft Press, 880 pages, 1993.
Retail price: $35.
ISBN: 1-55615-484-4.

Steve McConnell

source: http://www.construx.com/stevemcc/cc.htm

-john

Mohammad A. Haque

unread,
Nov 30, 2001, 1:37:45 PM11/30/01
to Dana Lacoste, linux-...@vger.kernel.org
On Friday, November 30, 2001, at 01:19 , Dana Lacoste wrote:

> This issue has gone beyond productivity to personal name calling
> and spurious defence. Can we all just move on a bit maybe?

Heh, are you kidding, This is LKML. It's gonna be beaten into the ground
and then some.

For what it's worth, most professional programmers I've interacted with
always adhere to the programming style of where they are working,
regardless of the way they personally program.
--

=====================================================================
Mohammad A. Haque http://www.haque.net/
mha...@haque.net

"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
batm...@themes.org
=====================================================================

Jeff Garzik

unread,
Nov 30, 2001, 1:39:12 PM11/30/01
to Henning Schmiedehausen, Larry McVoy, linux-...@vger.kernel.org
Diverse coding styles in the Linux kernel create long term maintenance
problems. End of story.

Jeff


--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

-

Paul G. Allen

unread,
Nov 30, 2001, 1:45:14 PM11/30/01
to kplug...@kernel-panic.org, Linux kernel developer's mailing list, kplug...@kernel-panic.org
"John H. Robinson, IV" wrote:
>
> On Fri, Nov 30, 2001 at 10:15:41AM -0800, Paul G. Allen wrote:
> >
> > IMEO, there is but one source as reference for coding style: A book by
> > the name of "Code Complete". (Sorry, I can't remember the author and I
> > no longer have a copy. Maybe my Brother will chime in here and fill in
> > the blanks since he still has his copy.)
>
> Code Complete: A Practical Handbook of Software Construction.
> Redmond, Wa.: Microsoft Press, 880 pages, 1993.
> Retail price: $35.
> ISBN: 1-55615-484-4.
>

Thanks John. You beat my bro. to it. Of course, he's probably still in
bed since it's not even noon yet. :)

(Note to self: Order a new copy of the book. I should have done it last
night when I ordered 3 other programming books. :/)

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Nestor Florez

unread,
Nov 30, 2001, 1:45:43 PM11/30/01
to kplug...@kernel-panic.org, Linux kernel developer's mailing list, kplug...@kernel-panic.org
Book : Code Complete
Author : Steve McConnell
Publisher: Microsoft Press

Nestor :-)

Maciej W. Rozycki

unread,
Nov 30, 2001, 1:47:43 PM11/30/01
to dal...@evision.ag, Russell King, linux-...@vger.kernel.org
On Fri, 30 Nov 2001, Martin Dalecki wrote:

> > Please explain. Especially contentrate on justifing why serial interfaces
> > aren't a tty device.
>
> No problem ;-).
>
> There is the hardware: in esp. the serial controller itself - this
> belongs
> to misc, becouse a mouse for example doesn't have to interpret any tty
> stuff

The same applies to the console keyboard, which is hooked to a standard
UART on certain systems as well.

--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ma...@ds2.pg.gda.pl, PGP key available +

Henning Schmiedehausen

unread,
Nov 30, 2001, 1:50:35 PM11/30/01
to Larry McVoy, Daniel Phillips, Jeff Garzik, linux-...@vger.kernel.org
On Fri, 2001-11-30 at 19:13, Larry McVoy wrote:

> But I haven't found anything else which works as well. I don't use that
> technique at BitMover, instead I rewrite code that I find offensive. That's

Sounds like the thing that Mr. Gates did when Microsoft was small. Maybe
there _is_ a point in this.

Regards
Henning


--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20

-

Martin Dalecki

unread,
Nov 30, 2001, 1:51:14 PM11/30/01
to Russell King, dal...@evision.ag, linux-...@vger.kernel.org
Russell King wrote:
>
> On Fri, Nov 30, 2001 at 06:49:01PM +0100, Martin Dalecki wrote:
> > Well sombeody really cares apparently! Thank's.
>
> Currently its a restructuring of serial.c to allow different uart type
> ports to be driven without duplicating serial.c many times over. (the
> generic_serial didn't hack it either).
>
> > Any pointers where to ahve a look at it?
>
> I should probably put this on a web page somewhere 8)
>
> :pserver:c...@pubcvs.arm.linux.org.uk:/mnt/src/cvsroot, module serial
> (no password)
>
> > BTW> Did you consider ther misc device idea? (Hooking serial at to the
> > misc device stuff).
>
> I just caught that comment - I'll await your reply.

I'm just right now looking at the code found above.
First of all: GREAT WORK! And then you are right a bit, I just don't
see too much code duplication between the particular drivers there.
However I still don't see the need to carrige the whole tty stuff just
to drive a mouse... but I don't see a solution right now.
I wouldn't be good to introduce a scatter heap of "micro"
driver modules like the ALSA people did as well too..

However in serial/linux/drivers/serial/serial_clps711x.c
the following wonders me a bit:

#ifdef CONFIG_DEVFS_FS
normal_name: SERIAL_CLPS711X_NAME,
callout_name: CALLOUT_CLPS711X_NAME,
#else
normal_name: SERIAL_CLPS711X_NAME,
callout_name: CALLOUT_CLPS711X_NAME,
#endif

What is the ifdef supposed to be good for?


One other suggestion serial_code.c could be just serial.c or code.c
or main.c, since _xxxx.c should distinguish between particulart devices.
It was a bit clumy to find the entry-point for me...
And then we have in uart_register_driver:

normal->open = uart_open;
normal->close = uart_close;
normal->write = uart_write;
normal->put_char = uart_put_char;
normal->flush_chars = uart_flush_chars;
normal->write_room = uart_write_room;
normal->chars_in_buffer = uart_chars_in_buffer;
normal->flush_buffer = uart_flush_buffer;
normal->ioctl = uart_ioctl;
normal->throttle = uart_throttle;
normal->unthrottle = uart_unthrottle;
normal->send_xchar = uart_send_xchar;
normal->set_termios = uart_set_termios;
normal->stop = uart_stop;
normal->start = uart_start;
normal->hangup = uart_hangup;
normal->break_ctl = uart_break_ctl;
normal->wait_until_sent = uart_wait_until_sent;

And so on....

Why not do:

{
static strcut tty_driver _normal = {
open: uart_open,
close: uart_close,
...
};

...

*normal = _normal;
}
...
for the static stuff first and only initialize the
dynamically calculated addresses dynamically later, like
the double refferences...
This would save already *quite a bit* of .text ;-).

Yeah I know I'm a bit perverse about optimizations....


You already do it for the callout device nearly this
way:

/*
* The callout device is just like the normal device except for
* the major number and the subtype code.
*/
*callout = *normal;
callout->name = drv->callout_name;
callout->major = drv->callout_major;
callout->subtype = SERIAL_TYPE_CALLOUT;
callout->read_proc = NULL;
callout->proc_entry = NULL;

Reagrds.

Russell King

unread,
Nov 30, 2001, 1:54:24 PM11/30/01
to Maciej W. Rozycki, dal...@evision.ag, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 07:40:29PM +0100, Maciej W. Rozycki wrote:
> The same applies to the console keyboard, which is hooked to a standard
> UART on certain systems as well.

This particular point is up for discussion between myself and James Simmons
(and other interested parties). We're getting there...

-

antirez

unread,
Nov 30, 2001, 1:56:53 PM11/30/01
to Paul G. Allen, Linux kernel developer's mailing list
On Fri, Nov 30, 2001 at 10:20:43AM -0800, Paul G. Allen wrote:
> antirez wrote:
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.

I agree, but descriptive != long

for (mydearcountr = 0; mydearcounter < n; mydearcounter++)

and it was just an example. Read it as "bad coding style".

--
Salvatore Sanfilippo <ant...@invece.org>
http://www.kyuzz.org/antirez
finger ant...@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

Jeff Garzik

unread,
Nov 30, 2001, 1:58:43 PM11/30/01
to Paul G. Allen, Linux kernel developer's mailing list, kplug...@kernel-panic.org, kplug...@kernel-panic.org
"Paul G. Allen" wrote:
> IMEO, there is but one source as reference for coding style: A book by
> the name of "Code Complete". (Sorry, I can't remember the author and I
> no longer have a copy. Maybe my Brother will chime in here and fill in
> the blanks since he still has his copy.)

Hungarian notation???

That was developed by programmers with apparently no skill to
see/remember how a variable is defined. IMHO in the Linux community
it's widely considered one of the worst coding styles possible.


> Outside of that, every place I have worked as a programmer, with a team
> of programmers, had a style that was adhered to almost religiously.

yes

> In 99% of the Linux code I have seen, the style does indeed "suck". Why?
> Consider a new coder coming in for any given task. S/he knows nothing
> about the kernel and needs to get up to speed quickly. S/he starts
> browsing the source - the ONLY definitive explanation of what it does
> and how it works - and finds:

99% is far and above the level of suck defined by most :)


> - Single letter variable names that aren't simple loop counters and
> must ask "What the h*** are these for?"
> - No function/file comment headers explaining what the purpose of the
> function/file is.
> - Very few comments at all, which is not necessarily bad except...
> - The code is not self documenting and without comments it takes an
> hour to figure out what function Foo() does.

We could definitely use a ton more comments... patches accepted.


> - Opening curly braces at the end of a the first line of a large code
> block making it extremely difficult to find where the code block begins
> or ends.

use a decent editor


> - Short variable/function names that someone thinks is descriptive but
> really isn't.

not all variable names need their purpose obvious to complete newbies.
sometimes it takes time to understand the code's purpose, in which case
the variable names become incredibly descriptive.


> After all, the kernel must be maintained by a number of people and those
> people will come and go. The only real way to keep bugs at a minimum,
> efficiency at a maximum, and the learning curve for new coders
> acceptable is consistent coding style and code that is easily
> maintained. The things I note above are not a means to that end. Sure,
> maybe Bob, the designer and coder of bobsdriver.o knows the code inside
> and out without need of a single comment or descriptive
> function/variable name, but what happens when Bob can no longer maintain
> it? It's 10,000 lines of code, the kernel is useless without it, it
> broke with kernel 2.6.0, and Joe, the new maintainer of bobsdriver.o, is
> having a hell of a time figuring out what the damn thing does.

yes

Jeff


--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

-

Jeff Garzik

unread,
Nov 30, 2001, 2:02:35 PM11/30/01
to Paul G. Allen, Linux kernel developer's mailing list
"Paul G. Allen" wrote:
> A variable/function name should ALWAYS be descriptive of the
> variable/function purpose. If it takes a long name, so be it. At least
> the next guy looking at it will know what it is for.

That's complete crap. Human beings know and understand context, and can
use it effectively. 'idx' or 'i' or 'bh' may make perfect sense in
context. There is absolutely no need for
JournalBHThatIsStoredAndSyncedWithSuperblock.

Kernel code like DAC960 proves that long variable names -decrease- code
readability.

Jeff


--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

-

Larry McVoy

unread,
Nov 30, 2001, 2:07:43 PM11/30/01
to Daniel Phillips, Larry McVoy, Henning Schmiedehausen, Jeff Garzik, linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 07:43:01PM +0100, Daniel Phillips wrote:

> On November 30, 2001 07:13 pm, Larry McVoy wrote:
> > On Fri, Nov 30, 2001 at 06:49:11PM +0100, Daniel Phillips wrote:
> > > On the other hand, the idea of a coding style hall of shame - publicly
> > > humiliating kernel contributers - is immature and just plain silly. It's
> > > good to have a giggle thinking about it, but that's where it should stop.
> >
> > If you've got a more effective way of getting people to do the right thing,
> > lets hear it. Remember, the goal is to protect the source base, not your,
> > my, or another's ego.
>
> Yes, lead by example, it's at least as effective.

I'd like to see some data which backs up that statement. My experience is
that that is an unsupportable statement. You'd need to know how effective
the Sun way is, have seen multiple development organizations using that
way and other ways, and have watched the progress.

I'm in a somewhat unique position in that I have a lot of ex-Sun engineers
using BitKeeper and I have a pretty good idea how fast they make changes.
It's a lot faster and a lot more consistent than the Linux effort, in fact,
there is no comparison.

I'm not claiming that the coding style is the source of their speed, but
it is part of the culture which is the source of their speed.

As far as I can tell, you are just asserting that leading by example is
more effective. Am I incorrect? Do you have data? I have piles which
shows the opposite.

> Maybe humiliation works at
> Sun, when you're getting a paycheck, but in the world of volunteer
> development it just makes people walk.

Huh. Not sure I agree with that either. It's definitely a dicey area
but go through the archives (or your memory if it is better than mine)
and look at how the various leaders here respond to bad choices. It's
basically public humiliation. Linus is especially inclined to speak
his mind when he sees something bad. And people stick around.

I think the thing you are missing is that what I am describing is a lot
like boot camp. Someone with more knowledge and experience than you
yells at your every mistake, you hate it for a while, and you emerge
from boot camp a stronger person with more skills and good habits as
well as a sense of pride. If there was a way to "lead by example" and
accomplish the same goals in the same time, don't you think someone
would have figured that out by now?


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

John Kodis

unread,
Nov 30, 2001, 2:43:13 PM11/30/01
to linux-...@vger.kernel.org
On Fri, Nov 30, 2001 at 02:00:18PM -0500, Jeff Garzik wrote:

> Human beings know and understand context, and can use it
> effectively. 'idx' or 'i' or 'bh' may make perfect sense in
> context. There is absolutely no need for
> JournalBHThatIsStoredAndSyncedWithSuperblock.

Mathematics has a rich tradition of using short variable names such as
"pi" rather than something like "circle-circumference-to-diameter-ratio".
They keep formulas from becoming unreadably long, and have a meaning
which is well understood in context. While the long version may more
self-explainatory, it's the short form which is universally preferred.

-- John Kodis.

RaúlNúńezde Arenas Coronado

unread,
Nov 30, 2001, 2:45:04 PM11/30/01
to jga...@mandrakesoft.com, pga...@randomlogic.com, kplug...@kernel-panic.org, kplug...@kernel-panic.org, linux-...@vger.kernel.org
Hi Jeff and Paul :)

>"Paul G. Allen" wrote:
>> IMEO, there is but one source as reference for coding style: A book =
by
>> the name of "Code Complete". (Sorry, I can't remember the author and=
I
>> no longer have a copy. Maybe my Brother will chime in here and fill =


in
>> the blanks since he still has his copy.)
>Hungarian notation???
>That was developed by programmers with apparently no skill to
>see/remember how a variable is defined. IMHO in the Linux community
>it's widely considered one of the worst coding styles possible.

Not at all... Hungarian notation is not so bad, except it is only
understood by people from hungary. So the name }:))) I just use it
when I write code for Hungary or secret code that no one should
read...

>> - Short variable/function names that someone thinks is descriptive =
but
>> really isn't.
>not all variable names need their purpose obvious to complete newbies.=

>sometimes it takes time to understand the code's purpose, in which cas=


e
>the variable names become incredibly descriptive.

Here you are right. The code can be seen really as a book: you
can start reading at the middle and yet understand some of the story,
but it's far better when you start at the beginning ;))) Moreover,
most of the variable and function names in the kernel code are quite
descriptive, IMHO.

Of course, more comments and more descriptive names doesn't harm,
but some times they bloat the code...

Raúl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=

Galappatti, Kishantha

unread,
Nov 30, 2001, 2:45:44 PM11/30/01
to Dana Lacoste, Larry McVoy, Henning Schmiedehausen, Jeff Garzik, linux-...@vger.kernel.org
i agree with that dana. Sure coding style is important but lets not get
personal here. I personally think there should be an established coding
style that should be kept to as much as possible but the way to implement
that is by helping the contributors to do so with tools etc, not by
castigating them in a "hall of shame". Isn't open source about inclusion and
creativity?
Just my opinion.

--kish

-----Original Message-----
From: Dana Lacoste [mailto:dana.l...@peregrine.com]
Sent: Friday, November 30, 2001 1:19 PM
To: 'Larry McVoy'; Henning Schmiedehausen
Cc: Jeff Garzik; linux-...@vger.kernel.org
Subject: RE: Coding style - a non-issue


Any chance that you guys could calm down a bit?

I bet the guys in Redmond who were referred to
earlier are enjoying it, but it's just trash for
the rest of us....

> Henning, perhaps you can explain to me how the following isn't a
>
> "I don't do XYZ"
>
> "XYZ"
>
> statement?

This one I understood though :
Al made a personal attack. He defended against the attack,
and preluded his defence with a disclaimer.

This issue has gone beyond productivity to personal name calling


and spurious defence. Can we all just move on a bit maybe?

Thanks

--
Dana Lacoste - Linux Developer
Peregrine Systems - Ottawa, Canada

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in


the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Paul G. Allen

unread,
Nov 30, 2001, 3:09:37 PM11/30/01
to Linux kernel developer's mailing list, kplug...@kernel-panic.org, kplug...@kernel-panic.org
Jeff Garzik wrote:
>
>
> We could definitely use a ton more comments... patches accepted.
>

I've actually thought of doing just that. :)

Alas, I'm too busy coding other things right now, so kernel stuff
(unless I need something to make the other project I'm working on
work/work better) will just have to wait. Hell, I'm even behind 2 or 3
kernel versions on the documentation I've been putting on my web site.
:(

> > - Opening curly braces at the end of a the first line of a large code
> > block making it extremely difficult to find where the code block begins
> > or ends.
>
> use a decent editor

A person shouldn't _need_ a decent editor to pick out the beginning/end
of a code block (or anything else for that matter). The problem is
exacerbated when such a block contains other blocks and quickly picking
out where each begins/ends becomes tiresome. I _do_ have excellent
editors, IDEs, and source code browsers and have used many different
kinds in many different jobs. They still can not replace what the human
eye and mind perceive.

>
> > - Short variable/function names that someone thinks is descriptive but
> > really isn't.
>
> not all variable names need their purpose obvious to complete newbies.
> sometimes it takes time to understand the code's purpose, in which case
> the variable names become incredibly descriptive.

It should not take "time" to discover the purpose of _any_ variable or
function, or file, whether newbie or not. The point of coding is to
solve a problem, not perform an excersise in deductive or logical
reasoning before the problem (which usually involves further logical
reasoning) can be solved.

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Jeff Garzik

unread,
Nov 30, 2001, 3:20:28 PM11/30/01
to Paul G. Allen, Linux kernel developer's mailing list, kplug...@kernel-panic.org, kplug...@kernel-panic.org
"Paul G. Allen" wrote:
> It should not take "time" to discover the purpose of _any_ variable or
> function, or file, whether newbie or not. The point of coding is to
> solve a problem, not perform an excersise in deductive or logical
> reasoning before the problem (which usually involves further logical
> reasoning) can be solved.

Part of the problem being solved by Linux kernel code is efficient long
term maintenance and efficient peer review. Overly verbose code does
not solve these problems.

Jeff


--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno

-

Paul G. Allen

unread,
Nov 30, 2001, 3:23:03 PM11/30/01
to Linux kernel developer's mailing list
antirez wrote:
>
> On Fri, Nov 30, 2001 at 10:20:43AM -0800, Paul G. Allen wrote:
> > antirez wrote:
> > A variable/function name should ALWAYS be descriptive of the
> > variable/function purpose. If it takes a long name, so be it. At least
> > the next guy looking at it will know what it is for.
>
> I agree, but descriptive != long
>
> for (mydearcountr = 0; mydearcounter < n; mydearcounter++)
>
> and it was just an example. Read it as "bad coding style".
>

Well if you're counting dear in the kernel, I'd say you have more
problems than your coding style. ;)

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Paul G. Allen

unread,
Nov 30, 2001, 3:30:06 PM11/30/01
to linux-...@vger.kernel.org
John Kodis wrote:
>
> On Fri, Nov 30, 2001 at 02:00:18PM -0500, Jeff Garzik wrote:
>
> > Human beings know and understand context, and can use it
> > effectively. 'idx' or 'i' or 'bh' may make perfect sense in
> > context. There is absolutely no need for
> > JournalBHThatIsStoredAndSyncedWithSuperblock.

JounalBH would be far better than i or idx.

>
> Mathematics has a rich tradition of using short variable names such as
> "pi" rather than something like "circle-circumference-to-diameter-ratio".
> They keep formulas from becoming unreadably long, and have a meaning
> which is well understood in context. While the long version may more
> self-explainatory, it's the short form which is universally preferred.
>

While 'pi', 'e', 'theta', 'phi', etc. are universally understood, things
like 'i', 'a', and 'idx' are not. I can use these for anything I want
and even for more than one thing, and they say nothing about what they
are for. 'i', 'j', etc. are fine as loop counters and array indexes
where their meaning is apparent by context, but are _not_ fine in other
situations. You (or the person that wrote the code) may think that the
name is perfectly fine, but someone else that thinks a bit different may
not.

PGA
--
Paul G. Allen
UNIX Admin II ('til Dec. 3)/FlUnKy At LaRgE (forever!)
Akamai Technologies, Inc.
www.akamai.com

Andrew Morton

unread,
Nov 30, 2001, 3:50:36 PM11/30/01
to Jeff Garzik, Linux kernel developer's mailing list
Jeff Garzik wrote:
>
> We could definitely use a ton more comments... patches accepted.
>

Too late. Useful comments go in during, or even before the code.

While we're on the coding style topic: ext2_new_block.

-

Tim Hockin

unread,
Nov 30, 2001, 4:22:37 PM11/30/01
to Paul G. Allen, kplug...@kernel-panic.org, kplug...@kernel-panic.org, linux-...@vger.kernel.org
> > Of course, more comments and more descriptive names doesn't harm,
> > but some times they bloat the code...
> >
>
> Actually it bloats the source (we all know C++ bloats the resulting code
> ;), but what's wrong with that? At least a person can understand what's
> going on and get to coding, instead of deciphering.

I'd happily download 50 MB kernel tarballs, if the extra 25 MB were
ACCURATE and UP TO DATE comments.

Larry McVoy

unread,
Nov 30, 2001, 5:08:54 PM11/30/01