Slashdot Mirror
Linus Torvalds In Sweary Rant About Punctuation In Kernel Comments (theregister.co.uk)
An anonymous reader shares a report on The Register: Linus Torvalds has unleashed a sweary rant on the Linux Kernel Mailing List, labelling some members "brain-damaged" for their preferred method of punctuating comments. "Can we please get rid of the brain-damaged stupid networking comment syntax style, PLEASE?" the Linux Lord asked last Friday. "If the networking people cannot handle the pure awesomeness that is a balanced and symmetric traditional multi-line C style comments, then instead of the disgusting unbalanced crap that you guys use now, please just go all the way to the C++ mode."Torvalds despises the following two comment-punctuation styles (with his comments):/* This is disgusting drug-induced
* crap, and should die
*/ and:/* This is also very nasty
* and visually unbalanced */Torvalds prefers the following two styles:/* This is a comment */ and:/*
* This is also a comment, but it can now be cleanly
* split over multiple lines
*/
* crap, and should die
*/ and:/* This is also very nasty
* and visually unbalanced */Torvalds prefers the following two styles:/* This is a comment */ and:/*
* This is also a comment, but it can now be cleanly
* split over multiple lines
*/
...I happen to agree with his stance on this particular issue.
Because of shit like this. fuck you.
I like to make people work harder to figure out what I did.
And if you didn't agree, would you have changed your stance or argued that he's a crackpot?
“Common sense is not so common.” — Voltaire
What happened in his childhood to arrest his development? Any shrinks in the house?
those first two examples are hideous. I guess before I comment more I should read the article?
Linus has been known as an acerbic and rude individual, but he's never dared to touch the sacred unbalanced comment before. He's gotten bolder as we've taken his stuff. We really should have held the line, called an end to it before now. This is what we get for pandering to him.
It's too late to simply eject him from kernel development. We can't have him hectoring us from the sidelines. I'm afraid that we must entirely erase Linus Torvalds from the noÃsphere.
Think of it as evolution in action!
rot13: whfg xvqqvat
Bruce Perens.
No bugs left other than comment style disagreements? Rejoice, the year of Linux on the desktop can't be far!
For what it's worth, my single contribution to the Linux kernel fucked up some white space. Torvalds didn't notice or I guess I would have woken up in the burn ward.
...they first cause comment syntax to twist their panties into a bunch.
Seeing as 'C++ mode' // comments were added to the C99 spec; this would be my preference. I've always hated all forms of /* */
I guess he doesn't like to be seen picking his nose :-)
Bruce Perens.
At last a Linux development post where everybody can have an opinion! Gone are the obscure race conditions and unstable semaphores, where prudent programmers preferred to watch in silence and seem ignorant, rather than open their mouths and dispel all doubts.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
That's formatting.
Yeah! It's not like the guy fucking invented Linux or something!
Does he have a passionate hatred for spacebar indents too?
it isnt always ideal to tab indent.
really, bitching over comment style? i cant wait to see the commit logs--"correct unapproved comment style, no changes in function."
what a brave new world...
Go ahead, point out where in here
labelling some members “brain-damaged”
is.
"your commenting style/code/idea/product/argument/... is stupid" != "you are stupid".
If you can't tell the difference, seek professional help.
As we step back and look at the overall quality of code these days, set to unleash that shitstorm on the IoT hell that will ultimately control the world around us...
...it sure is good to know that our "Linux Lord" has his /* fucking priorities */ straight worrying about comments.
Linus is right. I've been using the Linux kernel coding style as much as possible in all of my programming, regardless of the language, since around 1994. I get nothing but compliments.
When it comes to the kernel, the most important thing is writing code that other people can read and modify. Anybody can write new code. It takes an artist to write code that other people can easily understand.
First: I've had to use style cop. It sucks. ... we each have our own variation of 'style'; which can be seen here.
But
So, why not have a 'stylecop' that acts locally; on white space & comments? If I like 3 spaces, and you like 4; we can just get along. The style is formatted on view, not on compile.
This would also fix his problem: When he views it... it will 're-format' to something he likes to see.
How hard would it be to simply write a script to reformat all comments in the preferred style? Not that hard I imagine...
This comment will not be saved until you click the Submit button below.
You must wait a little bit (2 minutes) before using this resource; please try again later.
Maybe anyone who wants to get their kernel patches upstream?
“Common sense is not so common.” — Voltaire
The fact that this is what he decides to rant about is... probably a good thing.
My preferred coding style happens to be Whitesmiths. (Go ahead and laugh, but I'm used to it.)
Since not much new stuff outside of my own is written in Whitesmith's style, I use astyle to reformat the the other guy's code if I'm going to be studying it or adding to it or whatever. I actually have astyle fully integrated into both Geany and vim (the two code editors that I use) so I can reformat code instantly on demand.
I've never paid much attention to comment styles as such, but I'm sure that you can use astyle to reformat that if you want to; it has a million-and-one options available to put out all sorts of cats and make coffee.
So if Linus or anyone else doesn't like a C style, it takes almost no effort to reformat it to the style that you want. Then everyone gets to look at and use what he's comfortable with, and there's no friction at all.
If you're a zombie and you know it, bite your friend!
Poorly created comments are the work of the devil, plan and simple. Imagine working on a piece of software after it's been in active development for 10 years.
Some libraries just work and nobody's even looked at the code for 1/2 a decade. Shitty comments will kill you, or worse others...
Linus can be a needlessly pretentious ass about things, but I agree with him on this one.
Yes Francis, the world has gone crazy.
The Donald Trump of software developers.
They are not comments, they are Perl.
Table-ized A.I.
We're talking formatting here.
/**
* If you adhere to Doxygen style comments
* it clears this up nicely.
*/
I wish he would worry more about systemd and less about comments.
It is probably to help distinguishing comments from non-comments, especially when syntax highlighting isn't used, or in patch files.
Some text editors manage this style of comment quite well.
/*
* Guys, I already see a lot of badly formatted comments here.
* I thoroughly agree with Linus here, comments should be correctly formatted.
* Unbalanced comments should be removed and boxed comments are right out.
*/
It's probably not even the biggest thing on his "Kernel Shit Must Change" list; more of a "this came up, so here's my opinion; now I'm gonna do something else". At least, that's how I interpret his email.
But why would you expect to see stuff about war, famine, or the Kardashians on the linux kernel mailing list?
Some things are like Chinese water torture... how many years has he been doing linux kernal?
love is just extroverted narcissism
Lets start a 'things I hate' thread... I can't stand pluralizing database table names. Its redundant. Who is going to store one record in a table?
love is just extroverted narcissism
Next worst are ego comments. Every inline function preceded by three line comment naming the author as though he is Leo Tolstoy or she is Jane Austen.
Next worst are trivial comments. Next worst are no comments.
Then comes badly formatted comments.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
... just doesn't have the same click bait appeal does it? ;)
I think it might be fun to put Linus in a kitchen with Gordon just to give him a taste of his own medicine and vice versa
Those who get to the top of their profession are driven perfectionists who expect everyone else around them to strive to achieve that same level of perfection.
I get why they lose it with others less driven and focused.
Do they need perspective or should we just leave them alone to continue to be brilliant? I think the latter.
I'm more pissed off by the unnecessary leading *, since any editor worth a damn has syntax highlighting. It's his project though, so he can set whatever standard he wants and if you don't like that you can fork it. Once again, pretty much any style problem can be solved in the editor, and most editors already fix this problem; but that's just my opinion and it's worth less than his because I'm not leading a kernel project that runs bazillions of servers.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
many of us have worked on devices where EVERY byte of memory was a scarce resource. comments generally only live in source not binary but I had code where I even had to remove error handling to save a few bytes of memory in an EDI system.
/* ââ©â®(ÎY_ÎY)ââ©â® */
I hated using Windows for years because I thought that Bill Gates and friends were assholes for their business practices. Now I hate Linux, not because Linus has evil business practices, just because he's as much an asshole as they ever were.
I prefer // for single line comments /*
for multiple line
comments
*/
/* No Comment */
If Linux aims for the same level of polish and stability, it's not a bad idea to do the same. Someone else will likely have to fix bugs in your code at some point. Having a consistent style of comments and other things makes it faster to scan visually and spot problems for someone used to that style.
I love three-space indent!
Not really, but that's actually what I use because work mandates it. Apparently there was a big debate in the early days of the company between 2 and 4, so they compromised. Much of our coding standard is based on one particular engineer who had vision problems and needed to keep the number of columns restricted.
But you know what? It works. Millions of lines of code dating back two decades, and it's extremely consistent. Ninety percent of the code looks like it was written by the same engineer. That's what you want on a major project.
Though I will say that I've come to hate tabs in indentation. They're fine until they're not. At some point you end up using some tool where they don't look right.
My pet peeve, though, is trailing spaces. Any code management system should be designed to strip trailing spaces or block commits that contain them. I've seen far too many code merges break because of a disagreement on trailing spaces, and that's just dumb.
Man, don't go there.
It's common email convention now, at least in my experience - when you respond to someone, you put your response on top, so as the conversation chain grows, the order is the most recent (and therefore the most pertinent) to the oldest, descending. So you don't have to scroll through pages just to see the last reply.
Back in the day, on newsgroups, if you did that you'd get absolutely SCREAMED at for "TOP POSTING", because it was WRONG.
From the guardians of all that is right and wrong.
/*
* some
* people
* don't know
* how to speak
* in public
*/
Why wouldn't he simply codify his preferences? I hear, he still holds some sway among Linux developers — once a particular style is accepted by consensus, it becomes easier to convince folks to follow it...
Interestingly, the style Mr. Torvalds prefers has been part of BSD's style(9) manual for decades.
Maybe, he should leave children's to children and join a real OS-project...
In Soviet Washington the swamp drains you.
which is odd since it's pretty much the only thing C++ did right.
How about leaving out the crappy asterisks at the beginning of lines? They suck.
More years than he hasn't been doing the LInux kernel. He's 46 and he started 24 years go when he was 22. September 1991.
First: I've had to use style cop. It sucks. But ... we each have our own variation of 'style'; which can be seen here.
So, why not have a 'stylecop' that acts locally; on white space & comments? If I like 3 spaces, and you like 4; we can just get along. The style is formatted on view, not on compile.
This would also fix his problem: When he views it... it will 're-format' to something he likes to see.
Check out clang-format. It's by far the best code formatting tool I've used, and using it allows you to stop thinking about formatting. However, your idea of everyone reformatting the code all the time to their preferred style is silly. Set a project style, "document" it in a .clang-format file and require everyone to use it. Everyone working on a project can learn the project's style; the tool just helps to make sure that it's applied consistently.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It could have been a tabs vs spaces rant
We all know that didn't work out very well for Richard Hendricks
Next worst are no comments.
I disagree.
Uncommented code that needs comments is bad, but the best code doesn't need comments at all. If I write a piece of code that requires a comment to be understandable, that's a hint that I need to step back and rethink that code. Maybe name variables better. Maybe pull a chunk out into a separate function so I can name that (that's particularly useful with those one-line comments that explain the goal of a block of code). Maybe reorder or reorganize it so that it's clearer.
Sometimes, after all I can do, I still feel like I need a comment so I write one, trying to keep it as concise, accurate and readable (including formatting) as possible. But I always consider that a failure and know that if I were a better programmer I could have avoided it.
The reason it's a failure and that it's better to avoid writing comments if you can is because comments are much less well-maintained than the code they describe. That means that comments often become obsolete (what you called the "worst comments"). Comments that don't exist can't become obsolete.
Note that I'm talking here about internal comments, not interface documentation, and especially not Javadoc/Doxygen/etc. comments which are used to generate API documentation. Those are very valuable and should always be written. Even those should be kept concise, though, and redundancy should be avoided. There's no reason to restate the function signature. If the function and argument names are well-chosen, they can often stand on their own. Let them.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Yes, he has 3 children
"In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake."
I don't care if it's 90,000 hectares. That lake was not my doing.
I actually initially read it as "sweaty rant", and imagined Linus furiously typing the rant, with sweat dripping onto his keyboard. Probably because "sweary" is not a real word, and my mind sort of auto-corrected it to the closet match.
Don't fornicate. Seriously, just don't do it.
So what is it, tabs or spaces?
Humans ..er .. I meant Hackers .
/*
* This is a comment
* I hate comments
*/
As it is only once I do it in a software project I will indulge any style that is requested.......
Bring it on!
Can't we all just use our comments sense?
----------------------------------- My Other Sig Is Hilarious -----------------------------------
He said "crap".
That's "sweary"?
Fuck.
Watch this Heartland Institute video
I don't agree with this viewpoint at all.
I have been working on some scientific simulator code and the comments have the math equations that a block of code is based on. It makes it so much easier to understand since it is often not obvious how an equation is mapped into implementation (things like discretization make things far more complex).
Comments should not say what code does it should be why. I don't need you to see that your code is adding up a bunch of numbers but knowing why it is doing it is very important.
Computer modeling for biotech drug manufacturing is HARD!
The most important comments are the ones that specify "why not". Often we will implement the interface using some methods, after release we find the inadequacies and change the implementation. Often the first implementation would be simple, intuitive and the first thing anyone would think of. Now that implementation is gone, and new less obvious and often tricky things are introduced. If the "why this and not that" comment is missing, a later code review might remove the complex second implementation and restore status quo ante.
It is important to document why it is not done that way, what we intend to do. Without it we will be forced to constantly reverse engineer to understand the code and might repeatedly re learn the same lessons over and over again.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
TECO will solve all your problems.
Fiat Lux.
I have been working on some scientific simulator code and the comments have the math equations that a block of code is based on.
That is absolutely a case where comments are essential. Ideally, they should not only contain the equations, but something of the derivation of the mathematical expressions and the rationale behind their use. In some cases it *may* be possible to write code in such a way that the expression itself is clearly expressed in the code, so a comment specifying the expression would add nothing... but even in that case an explanation of why that expression is appropriate is essential for any future understanding of the code. And in many cases the constraints of the programming language to not allow easy, direct statement of the expression, either, and then the comment that contains the mathematical representation is essential.
I'm not claiming that it's always possible to eliminate comments, but they should be eliminated whenever it is possible, and whenever you find yourself needing a comment you *should* take a step back and see whether it's possible to make the code clear without one.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
... even the greats can go OCD on you.
I totally agree with him and I don't see why anyone would use the other comment style, which is very less practical
The most important comments are the ones that specify "why not".
Like complex mathematical derivations, that's another case where comments may be essential. My recommendation isn't to eschew all comments, it's to avoid duplicating in comments what can be just as clearly expressed in code... and to work hard to try to express the information in code rather than in comments. Doing so will make your code cleaner and much more maintainable.
My code isn't comment-free, but it is comment-light, and I think it has gotten much better since I adopted this policy (which, BTW, I should be clear that I didn't originate. I got the idea from one of Robert Martin's books on code craftsmanship.).
Some examples might help. Consider this case, where I had to write a comment to explain why not to do something. Or (to pick a section from the same file), look at this case which is interesting because the comment is very large -- as large as the code that it documents -- and because I think that without the comment it's really not clear why the code is doing what it's doing. I have toyed with various ways of refactoring that code to eliminate the need for the comment, but short of using something like a strategy pattern I can't find one that does the job. And even a strategy-based implementation would still require me to both ensure that the strategies are applied in the correct *order*, and to document what that order is.
Doh! I just noticed that that long comment has bit-rotted a little. It was originally written when the code only handled options 1, 3 and 6, so the concluding paragraph doesn't explain about options 2, 4 or 5, or why they're tested in the order they are. That example is an even better one than I thought, since it demonstrates both the need for and risks of explanatory comments.
That SoftKeymasterContext class, however, is an exception to the rule. It exists specifically to address a bunch of unusual corner cases and so it's not surprising that it requires much more explanation than 99% of code should. Here's a better example (chosen more or less at random from the same project) of what comment-free code should look like.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I once got a few points knocked off my working code because of comments. I was told I didn't have enough General comments. My next program had nice blocks of comments about General Lee, General Custer, and many other famous generals. My instructor wasn't nearly as amused as I was. Imagine that.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
That interpretation requires that comments have brains. They don't. So this particular remark can reasonably be read to impugn the author of the comments. However, it's also extremely likely that this is a case of hyperbole; in which case smiles are called for, not outrage.
Yes, English is annoying. Linus can be, too. :)
I've fallen off your lawn, and I can't get up.
You do realize that you can write object oriented code in C with structs and function pointers, don't you?
Take a look at Berkeley Sockets, as you go up the networking stack structs extend other structs, which is OO design.
In the real world, "learning some other guy's code base" sometimes would indeed take more time than rewriting it the first chance you get.
If you haven't learned what something does and how it does it, then how the f*ck are you going to succeed at rewriting it?
By re-implementing the functional requirement that is supposed to be met by the God-awful complicated (and most likely buggy) code from scratch. Typically you have to delve into existing code to integrate or to fix something. Most often to fix something. So in those cases:
Think clean-room re-engineering from specs. This happens all the time, a system or function F that is supposed to do A, but that it uses too much memory, or it is too slow, or it leaks resources.
Whatever, but you know what F is supposed to do.
And the code behind A is just nasty and impenetrable, so hard to untangle to simply fix what is broken.
So you implement it from scratch so that it does A without all the other unwanted shit. That's how it is done all too often in the real world.
has gone to his head.
./*bad
/*
good
*/
*/
is not the worst programming problem I see
Star Trek transporters are just 3d printers.
If he's complaining about comments, Linux must be close to perfect. Otherwise, he'd be worried about that instead.
Hell, I'm happy if my guys leave ANY comments in their code.
In the past I have seen very unprofessional comments. One where they bitched back and forth, calling each other names.... and so on. Even the women could get very testy.
At best your code can explain what it's doing, but not why or how. I mean, it's great that I can see you frob and then swizzle. But why frob first and swizzle second? Why frob at all? Why not frobnicate instead?
dom
Sometimes those sorts of things do require explanations which can't be made clear through naming. Most of the time, though, good naming and good code structure can explain everything except the road-not-taken questions... and it's relatively rare that the road-not-taken choice is actually important enough, or has sufficient non-obvious rationale, that it requires explanation. If it does, by all means put it in a comment, though -- and note that that sort of comment *doesn't* tend to become obsolete.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Oh lordy, OCD+ASD to the max methinks. If this trivia is enough for him to work up a head of steam then all else must be full of rosy awesomeness in Linuxland.
The importance of good commenting can be seen in this winning example of C code
https://github.com/c00kiemon5t...
main(C,V)
char **V;
* understand it look it
*/ up.) (In the C Manual)
{
char _,__;
while (read(0,&__,1) & write((_=(_=C_C_(__),C)),
_C_,1)) _=C-V+subr(&V);
}
(GRR, how do you tell slashdot to NOT ALTER THE FORMATTING AT ALL!?!?)
Yes, there's more (see link). But you can clearly see the importance of comments there.
Coding style is a vehicle to convey your brilliance. You're a decent programmer so conform to whatever the style is on the project you work in. Don't waste your precious short life on arguing about style.
For instance: In order to be able to comply to any coding style, I always set up my modules so that reordering members will not affect the functioning. Want to order constructors, getters/setters and/or other methods differently? Want to order static members in a very specific way? All fine by me.
Let's get the real issue at hand be dealt with.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Differences in our backgrounds explain the different emphasis we are placing on comments. But all three of us agree more than we disagree. Splitting hairs about the last 5% disagreement, while ignoring 95% agreement.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
But all three of us agree more than we disagree. Splitting hairs about the last 5% disagreement, while ignoring 95% agreement.
We're programmers :-)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It's way better to use Pascal-style comments:
{
This is a comment
}
(I started with Turbo Pascal, and the first time I saw C code I was so confused - It's all comments, how does this work at all?) :)
When Torvalds has the time to rant about comment formatting, then there can't be big problems in the code currently.
btw: There are tools to fix formatting automatically.
related: They don't use doxygen (like syntax)?
Braindead indeed.
Mouth-foaming fool Torvalds is at it again, trying to talk down on some normal and inconsequential commenting habits.
I would not be surprised if his preferences are in line with his coding preferences' in relation to braces, where he started a Holy Fulmination (t/m) against that guy with the beard.
Arrogant airheaded asshole.