I was recently reviewing the Linux kernel coding style guideline, and this got me thinking:

1) Indentation

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.


Ever since I first read that many years ago, a question lingured as to what was the greatest exception to this rule? The most I have ever personally counted, was 5, but I was only looking at one module. Still, I was curious as to why exactly they were not more strict, and more to the point, with what type of code were they least strict in applying this?

If anyone is good with Git and regular expressions, perhaps they can count the most successive \t's and post the blocks of code.

Also, on a tangentially related note, Linus recently showed this code at a TED talk:

enter image description here

That is right; 4 spaced indentation, despite the fact he says:

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

And yet here he is, committing self-heresy. Has he ever explained why he did this? Does he now just program in 4 spaced indentation?

closed as primarily opinion-based by Stephen Harris, Jeff Schaller, G-Man, Rui F Ribeiro, mosvy Dec 3 '18 at 7:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    So you basically want to do grep -Pl '^\t{6,}'on the entire Linux kernel? This will give you files with an identation of 6 or more – Panki Dec 2 '18 at 17:30
  • @Panki A good place to start, definitely. Of course you would have to track git patches/diffs too, to see if code was ever changed and taken out; I am not an expert with Git so I wouldnt know how to search that. – Akiva Dec 2 '18 at 18:48
  • 1
    vugraphs can't show even moderately long lines while keeping the font a readable size, so Linus can be forgiven for reformatting code to use 4-space tab stops. – Mark Plotnick Dec 2 '18 at 20:36

What is the highest level of indentation today [in] the Linux Kernel?

53 in drivers/pcmcia/vrc4173_cardu.c and sound/pci/cs46xx/dsp_spos_scb_lib.c on the linux-4.14.y branch but as you can see that's comment aligning, and wrapping function parameters, not a block indent for which tabs are used. This is the tip of the code formatting iceberg so to speak. Take a close look as the eclipse formatter and you will find hundreds of options.


while read -r F ; do
    while read -r L ; do
        FC=$(echo -n "$L" | perl -pe 's/^([\t ]*)[^\t ].+$/$1/g' | wc -c)
        if [ "$FOC" -gt 0 ] ; then
        if [ "$FC" -gt "$FOC" ] && [ "$FC" -gt "$FMAX" ] ; then
        if [ "$FMAX" -gt "$MAX" ] ; then
            echo "new max is $MAX in $F"
    done < "$F"
done < <(find . -iname '*.c' | xargs -I {} grep -lPm 1 "^[\t ]{50,}" "{}")

Looking at absolute tabs the winner is drivers/scsi/BusLogic.c with 20.

> find . -iname '*.c' | xargs -I {} grep -HPm 1 "^\t{20,}" "{}"

Or looking at absolute spacing there are 238 in drivers/pcmcia/i82092.c

> find . -iname '*.c' | xargs -I {} grep -HPm 1 "^ {238,}" "{}"

What is the highest level of indentation ... ever merged into the Linux Kernel?

That would be hard to answer because not all history is kept. It would be easy (but slow) to answer "ever merged into the current tree". But if you still want the answer to that make a second question so as to not make this one to broad.

Why exactly they were not more strict?

Linux is a "get it working and sort out ideology later" sort of solution (it's monolithic, with an ever changing API, closed blobs, etc). Also historically they simply did not have the tooling for non-trivial indentation, git was built for the kernel only when they needed it. There were more important things to do, but it looks like there was/is a non-exhaustive format check on the code called checkpatch.pl "as a guide"... but there are still gems in the code like the comment in dsp_spos_scb_lib.c that reads;


...so yes a lot of cleanup could be done, but people would rather not break what works, and if there is bad formatting somewhere it's likely the code also needs fixing in that location.

Has [Linus] ever explained why he did this?

It appears he prefers tabs to spaces (changing indentation length with tabs is one setting, vs refactoring a whole code base if spaces are used) but spaces are used to align wrapped functions instead of inserting a tab on the first line, so this makes the space to tab ratio (8:1) important.

Does he now just program in 4 spaced indentation?

No; Tabs are used in all c files in the kernel (5 files have no indentation though);

> find . -iname '*.c' | wc -l
> find . -iname '*.c' | xargs -I {} grep -m 1 "\t" "{}" | wc -l
> find . -iname *.c | while read F ; do C=$(grep -c "\t" "$F"); if [ $C == 0 ] ; then echo $F ; fi done

Note that most of the kernel is c files;

> find . -type f | perl -pe 's/.*\.//g' | sort | uniq -c | sort -nr | head
  25574 c
  20046 h
   3990 txt
   1443 S
   1391 dts
   1075 dtsi
    810 rst
    204 gitignore
    191 sh
    189 json
  • Are you sure about 53? I checked, and the comments do not indicate to me anywhere 53 levels of indentation. elixir.bootlin.com/linux/v4.14.85/source/sound/pci/cs46xx/… In Regex, ^\t{9} was the highest I could find, which was of course not a true indentation but wrapping parameters. – Akiva Dec 2 '18 at 19:06
  • Also, from what I saw, the true highest indent in that file was 4. – Akiva Dec 2 '18 at 19:10
  • Right, you were looking at spaces. Can you do it for \t tabs? I guess another way we could potentially search this, is seeing the widest character width on a line of code, although I would not know how to express that in Regex. – Akiva Dec 2 '18 at 19:20
  • Dont worry, I always accept the answer. I am a bit tired right now, but effectively we would have to refine the regular expression to account for the actual indentation of the code block. In your example, the twenty tabs was on account of a line break in the middle of a statement, where as the statement itself was only two indentations deep. – Akiva Dec 2 '18 at 22:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.