私は最近、Linux Kernel Coding Style Guideを見直しましたが、次のような気がしました。
1)インデント
タブ文字が8文字なので、インデントも8文字です。インデントを4文字（または2文字！）の深さに設定するという異端な動きがあり、これはPI値を3として定義したいのと似ています。
理由：インデントの基本概念は、制御ブロックが開始および終了する場所を明確に定義することです。特に、20時間画面を見続けると、インデントが大きくなるほど、インデントがどのように機能するかを確認するのが簡単になります。
今では、8文字のインデントが原因でコードが右に移動し、80文字の端末画面で読みにくくなると主張する人もいます。答えは、3段階以上のインデントが必要な場合はどうせ問題があるので、プログラムを修正しなければならないということです。
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
数年前、この記事を初めて読んだときから、1つの質問が私の心の中に浮上しました。このルールの最大の例外は何ですか？私が個人的に数えた最大数は5つですが、モジュール1つだけ見ています。しかし、なぜそれほど厳密ではないのか疑問に思いますが、もっと重要なのは、これを適用するときにどのような種類のコードに最も厳しくないのですか？
誰かがGitと正規表現に精通している場合は、おそらく最も連続的な数字を\t数えてコードブロックを投稿できます。
さらに、Linusは最近TED講演で次のコードを示しました。
そうですね。彼は次のように言いましたが、インデントは4つです。
タブ文字が8文字なので、インデントも8文字です。インデントを4文字（または2文字！）の深さに設定するという異端な動きがあり、これはPI値を3として定義したいのと似ています。
しかし、ここで彼は自分の異端を犯しました。彼がなぜこのようなことをしたのか説明したことがありますか？今はインデントスペースを4つだけプログラムしますか？
ベストアンサー1
現在、Linuxカーネルで最も高いインデントレベルは何ですか？
53drivers/pcmcia/vrc4173_cardu.c と linux-4.14.y ブランチの sound/pci/cs46xx/dsp_spos_scb_lib.c にありますが、タブ文字ブロックのインデントを使用する代わりに、コメントの並べ替えと関数パラメータのラップです。これは、コードフォーマットの氷山の一角と呼ばれることがあります。 Eclipseフォーマッタを詳しく見ると、何百ものオプションがあります。
#!/bin/bash
IFS=''
MAX=0
while read -r F ; do
FMAX=0
FC=0
FOC=0
while read -r L ; do
FC=$(echo -n "$L" | perl -pe 's/^([\t ]*)[^\t ].+$/$1/g' | wc -c)
if [ "$FOC" -gt 0 ] ; then
FOC="$FC"
continue
fi
if [ "$FC" -gt "$FOC" ] && [ "$FC" -gt "$FMAX" ] ; then
FMAX="$FC"
fi
FOC="$FC"
if [ "$FMAX" -gt "$MAX" ] ; then
MAX="$FMAX"
echo "new max is $MAX in $F"
fi
done < "$F"
done < <(find . -iname '*.c' | xargs -I {} grep -lPm 1 "^[\t ]{50,}" "{}")
絶対タブを見ると、勝者はdrivers/scsi/BusLogic.cです。20。
> find . -iname '*.c' | xargs -I {} grep -HPm 1 "^\t{20,}" "{}"
または絶対間隔を見てください238drivers/pcmcia/i82092.cから
> find . -iname '*.c' | xargs -I {} grep -HPm 1 "^ {238,}" "{}"
Linuxカーネルに統合された最高レベルのインデントは何ですか？
これはすべての歴史が保存されているわけではないため、答えにくいです。 「現在ツリーにマージされたことがあります」と答えるのは簡単ですが遅いです。しかし、まだこの質問に対する答えを知りたい場合は、この質問が広範囲にならないように2番目の質問をしてください。
一体なぜもっと厳しくないのですか？
Linuxは、「最初に動作させ、後で理念を整理する」ソリューションです（継続的に変化するAPI、クローズドブロブなどを備えたモノリシックです）。そして歴史的に、彼らは重要なインデントのためのツールを持っていませんでした。 gitは必要なときだけカーネル用に構築されました。もっと重要なことはありますが、checkpatch.pl"というコードで包括的ではない型チェックが行われているようです。"ガイド"...しかし、dsp_spos_scb_lib.cのコメントのように、コードにはまだいくつかの宝石があります。
これは私が作ったたわごとです。
...そうです。多くのクリーンアップタスクを実行できますが、タスク機能を中断しないことをお勧めし、どこかに型エラーがある場合はコードも修正する必要があります。
[リヌス]がなぜこのようなことをしたのか説明したことがありますか？
彼はスペースよりもタブを好むようです（タブを使用してインデントの長さを変更するのは設定です。スペースを使用する場合はコードベース全体をリファクタリングすることです）。ただし、スペースは最初の行にタブ文字を挿入する代わりにラップされた関数をソートするために使用されるため、スペースとタブの比率（8：1）が重要です。
今はインデントスペースを4つだけプログラムしますか？
いいえ。カーネル内のすべてのcファイルはタブを使用します（ただし、5つのファイルにはインデントはありません）。
> find . -iname '*.c' | wc -l
25575
> find . -iname '*.c' | xargs -I {} grep -m 1 "\t" "{}" | wc -l
25570
> find . -iname *.c | while read F ; do C=$(grep -c "\t" "$F"); if [ $C == 0 ] ; then echo $F ; fi done
./sound/pci/ens1371.c
./sound/isa/sb/sbawe.c
./drivers/scsi/pcmcia/aha152x_core.c
./drivers/scsi/pcmcia/fdomain_core.c
./drivers/scsi/sun3_scsi_vme.c
ほとんどのカーネルはcファイルです。
> 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