Also it's the other way around! Using common idioms builds culture how we structure our code. Then that common culture help make the idioms part of the shared vocabulary.

Working with such a large piece of code as the kernel, it's invaluable to have a certain sense of shared ideals how the code should read, and it's probably a good thing to have maintainers that nitpicks about such details.

People sometimes say things like "just a matter of taste" as if that somehow made it less important, but taste is probably the most important trait we can share when programming.

this is the big point. when coding alone I strongly prefer Linus's version.

but it seems to cause friction and get called out whenever I use it in a group environment. so I don't. or I change it.

the code itself isn't important. its about the functioning of the group, the velocity, and the ownership.

Well, yeah. This sort of code acts as a natural filter.

Someone's who finds it difficult to learn or to use it may not be ready for the kernel development. So it works as expected on more than one level.

The same goes for intrusive containers and few other things that many people learn in school, but get at first confused by in practice. If this creates a friction at the group level, then it's the problem with the average group skill rather than the code. And it's the former that (ideally) needs addressing. Just like you wouldn't use bubble sort because the "group" has trouble understanding the alternatives.

> the code itself isn't important. its about the functioning of the group, the velocity, and the ownership.

It isn't either/or. It can be all of the above, to varying degrees, that change over time.

The same argument was made recently about the reduce function: it's a known pattern for some and a hard to understand trick for others.

Yes, and you get used to reduce. map, filter and reduce were hard for me to follow… until I used them two or three times and now I understand them easily and they naturally come to my mind when I need to solve a problem which they can help solving.

They are good tools (especially in codebases shared with people who are allergic to loop statements!)

Agreed for map, filter etc. but reduce is the exception. There has been a fad of overusing it, until that article popped up which called it out.

I "got" reduce not long ago. It's occasionally handy, and it makes sense, but sure, it should not be overused. It is the most complicated between the three.

A good old loop in code bases that are not afraid of them are totally fine and probably clearer in many cases.

How I wish more programmers would understand this. It's like learning to eat broccoli. At first, its bitter and unfamiliar, but if you are exposed to it, you learn to recognize it and like it, and it's actually good for you despite the initial unpleasant taste.