Coding style - a non-issue
Peter Waltenberg
"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
>
> "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
> 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
> 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
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
> 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
> > 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
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
>
>>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
> 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
> 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...
>
> >people learn quickly. Being nice is great, but nothing works faster than
> >a cold shower of public humiliation :-)
>
> 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
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
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
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
> 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
> 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.
>
> 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
>
> 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
> 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
> 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
> 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.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Martin Dalecki
>
> > 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
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
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
>
> 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
> 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
> 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 (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Russell King
> 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.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Martin Dalecki
>
> 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
"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
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
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
> 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
>
> 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
> 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