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.
-----Original Message----- From: Dana Lacoste [mailto:dana.laco...@peregrine.com] Sent: Friday, November 30, 2001 1:19 PM To: 'Larry McVoy'; Henning Schmiedehausen
Cc: Jeff Garzik; linux-ker...@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 majord...@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 the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"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
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This is my last post on this topic, I don't think I can say more than I have.
On Fri, Nov 30, 2001 at 10:54:39PM +0100, Daniel Phillips wrote: > On November 30, 2001 08:05 pm, Larry McVoy wrote: > > 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.
> There's an additional pattern, you'll notice that the guys who end up wearing > the dung are the ones with full time Linux programming jobs, who basically > have no option but to stick around. Do that to every newbie and after a > while we'll have a smoking hole in the ground where Linux used to be.
> A simple rule to remember is: when code is bad, criticize the code, not the > coder.
Your priorities are upside down. The code is more important than the coder, it will outlive the coder's interest in that code. Besides, this isn't some touchy feely love fest, it's code. It's suppose to work and work well and be maintainable. You don't get that by being "nice", you get that by insisting on quality. If being nice worked, we wouldn't be having this conversation.
> > 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.
> Thanks, but I'll spend my summer in some other kind of camp ;-) I'm sure it > works for some people, but mutual respect is more what I'm used to and prefer.
The problem here is that you are assuming that yelling at someone means that you don't respect that someone. Nothing could be further from the truth. If you didn't respect them enough to think you could get good results from them, I doubt you'd be yelling at them in the first place. Don't confuse intense demands for excellence with a lack of respect, that's not the case.
> > 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?
> Somebody did, and as hard as it is for some to fit it into their own model of > the universe, there is somebody leading by example, not running a command > economy but a self-organizing meritocracy. Do we achieve the same goals in > the same time? Sometimes it doesn't seem like it, but because this thing > just keeps crawling relentlessly forward on a thousand fronts, in the end we > accomplish even more than Sun does.
Bah. Daniel, you are forgetting that I know what Sun has done first hand and I know what Linux has done first hand. If you think that Linux is at the same level as Sun's OS or ever will be, you're kidding yourself. Linux is really cool, I love it, and I use it every day. But it's not comparable to Solaris, sorry, not even close. I'm not exactly known for my love of Solaris, you know, in fact I really dislike it. But I respect it, it can take a licking and keep on ticking. Linux isn't there yet and unless the development model changes somewhat, I'll stand behind my belief that it is unlikely to ever get there. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Fri, 30 Nov 2001, Andrew Morton wrote: | Larry McVoy wrote:
| > | > Linux isn't there yet | > and unless the development model changes somewhat, I'll stand behind my | > belief that it is unlikely to ever get there. | | I am (genuinely) interested in what changes you think are needed.
Same here, regarding both development model and OS functionality, reliability, etc. -- ~Randy
|> 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.
Code serves two masters - it instructs computers, and it instructs humans (code readers, maintainers, forgetful authors a month later, ...).
Often the first master, the computer, is the less demanding. One can usually beat the code into submission with enough effort, even if uninspired. There are exceptions to this, such as perhaps virtual memory and C++ compilers, which get just plain hard for most humans.
The second master is usually the more demanding. Great code not only works, but is also a delight to read and maintain.
Like literature, there is perhaps a typical taxonomy of code, by how readable it is:
- there's quick draft hurried code with terse names and confused structure, free of comment - there's more methodical, verbose code - overburdened with uninspired, but exhaustive comments and baroque code embellishments - there's the eloquent gem, the polished pearl, the O'Henry short story, the Dijkstra algorithm - which looks sometimes like the hurried quick draft until you realize how hard it is to improve or simplify it, and until you observe either the many discarded drafts on the cutting room floor, or that the author was inspired with genius.
So, yes, overly verbose code doesn't solve problems, but it might show more effort to communicate with humans than confused early drafts.
Unfortunately, that extra effort can sometimes be more of an impediment than a help. It can be easier to nurse terse early confused drafts into decent code than overweight bloat ... less shit to shovel.
--
I won't rest till it's the best ... Manager, Linux Scalability Paul Jackson <p...@sgi.com> 1.650.933.1373
