Linux kernel coding style
kernel.org
kernel.org
People bikeshed source code formatting. They make arguments about developer portability and visual minutiae, usually without any sort of evidence, when in reality the higher-level organization of the code matters a lot more. Optimizing code for readability quickly runs into diminishing returns and begins hurting a lot more than it helps.
In general, I'm strongly against rules and ceremony and centralization when it comes to coding. Ostensibly, it's all about hygiene and best practices and whatever, but in practice this kind of discipline amounts to "I like it this way and you're going to like it too". It's far more important to let developers make decentralized, rapid decisions about the best approach for a particular task than to enforce some kind of useless Procrustean uniformity on everyone.
I've been coding according to these guidelines for quite a while with some minor modifications:
Always use curly braces (especially when you're not alone coding in the codebase as it allows for easy modification without code ending up out of the intented scope).
80 char width; well I don't follow this one as I really do prefer long lines over broken lines for readability.
Other than that I think these guidelines are great and offer consistency and easy to read code, in my opinion.
But I agree, after a few levels of indentation (which is sometimes unavoidable) you end up struggling.
That said, it's certainly a concern worth being aware of where it's relevant.
int usb_control_msg(struct usb_device * dev, unsigned int pipe, __u8 request, __u8 requesttype, __u16 value, __u16 index, void * data, __u16 size, int timeout);
So it is kind of hard to avoid going over the limit.
What we end up doing is break each argument into one line, like this (I hope the formatting comes out all right):
int res = usb_control_msg(
dev,
usb_sndctrlpipe(dev, 0),
0x41,
...
It's not so much of an eye-sore.
Line length isn't going to have much impact on what fits over ssh...
That said, yes, I was picking a nit mostly because the nit itself amused me (and I hoped it would amuse others) - it wasn't meant as significant criticism of your post.
I just prioritize to have "readable" code in my editor as first prio, second would be sites like Github on desktop and if it works good on a mobile phone that's a plus but not high prio for me.
(To be honest though I do actually glance through some Github reviews on my phone, but since it's pretty limited I do find myself thinking that I should get to a computer and do a real review there instead.)
And, yes, if any meaningful comments are needed I wait until I'm back at my laptop.
Also, emacs has glasses-mode, so when I have to work on a code base that uses camel case, at least I don't have to squint really hard. ;-)
> Not using braces for conditions followed by single line statements.
> Using abbreviations.
This is enough for me to say fuck this guide.
1. always use curly braces
2. 4 spaces instead of a tab character
if (var1 != var2) return false;
#define unless (x) if (!(x))
unless (f = popen("ps -axf")) die("popen of ps -axf");This refers to systems hungarian, the brain-dead twin of apps hungarian. The latter can be useful in C.
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
Also, please limit your lines to 80 characters. https://sr.ht/toyc.jpg
Assuming indentation is counted against those 80, why not use a bigger monitor?
More practically, a lot of people (myself including) will split their monitor vertically to consider lots of code at once, and talk about code in emails via patches on mailing lists and such where 80 columns is the norm.
C programmers tend to forget this wise recommendation.
int mytype;
typedef struct { ... } mytype;
Is that the thinking or is it something else?
You call out one upside - decreased verbosity. The accompanying downside is usually - as in this case, for both structs and pointers - that potentially relevant information is made less visible. Whether it's a good idea depends on how likely that information is to be actually relevant, weighed against the upsides.
Where performance is relevant, you want to be aware of where you're potentially passing large structs around. Putting this info in the type name instead is an option (eg _s), and can reduce verbosity a bit. I don't know of any good reasons to call out structs that are sized like primitives.
The case against hiding pointers is much stronger. Level of indirection can be relevant to performance, and is often relevant to correctness, particularly where mutation is involved. You can put it in the type name, but it's not going to be any less verbose - a star is already one character. I allow a possible exception here for where an opaque type is allocated by a library and passed around as a handle and the client really doesn't need to ever know whether it's a pointer or an int index or what.
> First off, I’d suggest printing out a copy of the GNU coding standards...
Which suggests this was written from the point of view of a specific person. In which case, it should attribute the author somewhere. I couldn't find a byline anywhere. Also, no date.
You could look in one of the historical trees.
is the original history from the BitKeeper repo.
[1] https://github.com/torvalds/linux/blame/master/Documentation...
indent wrong and it doesn't run.
Yuck. Abbreviations are usually bad. For one thing, people tend to pick different ways to abbreviate things so an hour later when you're trying to grep for where the variable was used you have to try to remember whether the variable was written tmp, temp, or temporary.
In this example, "temporary" is probably the least useful thing to know about the variable, since most variables are temporary. How about "counter"?
My favorite example: I was writing some graphics code recently, and some reviewer said: "I don't understand this uv abbreviation that appears all over the code. Please expand it."
headdesk.gif
(For those who aren't familiar: u and v are conventional names of texture coordinates, like x, y, and z are conventional names of spatial coordinates. There's no abbreviation to expand.)
I skipped to i and j, but I am certain there are mathematicians out there who find that confusing, too.
I guess, it's about context, too, at least a little.
IME it's pretty standard in most of mathematics to use "i" and "j" as index variables when e.g. doing sums and products over indices/sets. (Though I suppose you could be talking about the use of i, j, k as axes?)
What does one for index variables in that notation? Or is the main point of q notation that you don't need index variables? ;)
It's all about knowing what should be abbreviated and what shouldn't.
Why would one be forgetting and grepping for tmp? That's the kind of variable that would be inside a function (so max one or two screenfuls, according to the guidelines here), and more realistically would usually be declared and used entirely within the same block of a dozen or so lines of code. Nobody is going to forget whether it is temp or temp while reading those 12 lines of code. And using temporary is just silly -- I can't think of a single time I've ever seen that used in any language.
I'm struggling to think of any case where "tmp" couldn't be replaced by a better name. It's always going to be a temporary something.
I'm not arguing against short, concise names where they won't cause problems. Variable names of e.g. x, y, i all have their place.
If you have a variable tmp that's defined 6 pages back or worse, is global -- consider refactoring first, not just a more descriptive name.
I hope some JS programmers read this
It was good advice.
There's reasons to keep the block inline too--like if you're working in a more resource constrained environment, or if the block isn't really isolated/self-contained enough to cleanly abstract away, or if the block in question isn't really doing anything substantial. But I wouldn't say that you should only abstract away code into functions to save yourself from literally copy/pasting the lines in multiple places.
The kernel guideline doesn't mention this due to being C specific. C++ can exhibit similar issues.
Anonymous callback:
Foo.foo(() -> bar());
private final class MyFooDelegate implements FooDelegate {
@Override
public void doFoo() {
bar();
}
}
...
Foo.foo(new MyFooDelegate())