Linux Kernel 2.2 Documentation:
/usr/src/linux/Documentation/CodingStyle
CodingStyle
Linux カーネルのソースコードの好ましい書き方
[プレインテキスト版]
- 原著作者: Linus B. Torvalds
- 翻訳者: 山崎康宏
- バージョン: 2.2.0
- 翻訳日時: 1997/06/27
Linux流プログラム書法
Linus B. Torvalds 原著
山崎康宏 翻訳 (June. 27, 1997)
※ニコちゃんマークなどは訳者の趣味で加えたものです。(^_^;;)
ビールでも飲みながらリラックスして読んでみてください。
なお、原文はお手持ちのLinuxカーネルに附属しています。
この文書で、Linux カーネルのソースコードの好ましい書き方を簡単に説明して
みます。プログラム書法は多分に趣味的なものだから、僕の考えを無理やり押し
つけるつもりはありませんよ。でも、これから説明するのは僕が管理できなくて
はらならないもの全てに適用してきている方針だし、僕は自分が管理しないもの
でもこの方針で書かれていれば良いのになぁとさえ思っています。せめて、この
文書の内容を検討するだけでもしてみてくださいね。
では最初から思いっきり飛ばしますよ〜ん。まずは「GNU 標準プログラム書法」
(GNU coding standards)を入手して印刷してみてください。でも、読むために
印刷するのではありません。印刷した物を燃やすのです！この儀式は晴れがま
しい決意表明なのです！ V^_^V
では、この調子で本題に入りましょう：
第１章：字下げ
タブは８文字ごとですし、字下げも８文字でするもの。字下げを４文字でしよ
うとしたり、更には２文字単位でしようというような異教徒の運動まであるけ
ど、これはπ＝３と決めてしまおうという主張と同じようなもの。
【論拠】そもそも字下げを行おうというのは、ブロックの始まりと終わりがはっ
きりと分かるようにするため。大きな字下げがしてあれば、２０時間連続して
モニターを眺めているような時などには特に恩恵を実感できるものです。
さて、人によっては「８文字単位に字下げをするとプログラムが右に行き過ぎ
て、８０文字の画面では読みにくくなってしまう」と言うでしょう。こういう
人達には、「３段階より多くの字下げをするような場合はプログラムそのもの
が良くないんだから、そこから直しなさい。」と言っておきましょう。
要するに、８文字単位の字下げをすればプログラムが読みやすくなって、その
上、ループが深過ぎる関数を書いてしまった場合の警告にもなるのです。警告
を素直に聞き入れてくださいね。
第２章：括弧の位置
もう一つ、Ｃ言語のプログラム書法でよく話題になるのが括弧の位置。字下げ
の場合とは違い、正直言ってどこに括弧をおくのが優れているかというような
具体的な根拠はありません。それでも好ましい括弧の位置というのはあって、
Kernighan・Ritchie両氏によるＣの聖典（通称 K&Rと呼ばれる「プログラミン
グ言語Ｃ」）に示されているのです。ブロックの開始行の行末に開き括弧を置
いて、ブロックの最終行の始まりに閉じ括弧を置くというもので、以下のよう
になります：
if (xが真である) {
yを実行;
}
ただし、関数定義の括弧だけは例外で、開始の括弧は次の行の始まりに置きま
す：
int 関数名(int x)
{
関数の中身
}
ところが世界中の異教徒たちは、この首尾一貫性の無さが、なんというか...
えーと...首尾一貫していないと文句を言っています。しかし、正統派の人々
は(1)K&Rは正しく、しかも(2)K&Rが正しいのだとわかっているのです。それに、
そもそも関数定義というのはＣの中で特別なものなのです（関数定義の入れ子
はできないでしょ）。
ここで一つ注意しておきます。閉じ括弧は普通は閉じ括弧だけの行になるんだ
けど、閉じ括弧で文が終わらない場合にはその行が続くことになる。具体的に
は、do文の while と if文の else が来ることがあって、
do {
doループの中身
} while (ループ継続条件);
や、
if (x == y) {
..
} else if (x > y) {
...
} else {
....
}
などとなるのです。
【論拠】聖典『K&R』。
それに、ここで説明したように括弧を置けば、読みやすさを犠牲にしない範囲
で、空っぽの行（というか、ほとんど空の行）を最小限にとどめることが出来
るでしょ。画面に表示できる行は限られているから（私は２５行の端末画面を
念頭に置いて話をしています）、無駄のない書式で行を有効利用してコメント
を入れる行でも確保しましょう。
第３章：名前の選択
そもそもＣ言語はスパルタ言語なのですから、変数や関数の名前も厳しく選び
ます。説明的な名前を選ぶ Modula-2 や Pascal のプログラマとは違って、Ｃ
プログラマたるものは 「この変数は一時的に使われるカウンターなのであ〜
る(ThisVariableIsATemporaryCounter)」などという長い名前の変数は使いま
せん。Ｃのプログラマなら tmp という単純な名前を選ぶものです。書きやす
く、それでいて十分に分かりやすい変数名を選ぶのです。
ここでまた少し注意しておくと、基本的には大文字小文字を混ぜたような超賢
い名前は避けるんだけど、グローバル変数などには説明的な名前が必要ですよ。
グローバル関数にhogehoge()などという無意味な名前を付けるのは言語同断。
グローバル変数（本当に必要な時にだけ使ってね）には意味がよく分かる名前
を付けてください。グローバル関数も同じで、アクティブなユーザを数えるグ
ローバル関数にはcount_active_users()といった名前を使うべきで、cntusr()
ではダメ。
関数の型を関数名に含める方式（通称ハンガリー方式）なんて使う連中もどう
かしてる。そんなことをしなくてもコンパイラは型を知っているし、型チェッ
クもできる。結局はプログラマ自身を混乱させるのがおち。Microsoft が不安
定なプログラムを作っているのもうなずけるよね。
ローカル変数の名前は短くて、変数の性質をズバリと表したものを選びます。
例えば、ループの実行回数を数える適当な整数カウンタは i と名付けるのが
良くて、誤解される恐れもないのに loop_counterと呼んでも無駄なだけ。そ
れから、一時的に値を保持するテンポラリ変数は型に係わらず tmp と呼びま
しょう。
ちなみに、もしローカル変数を誤用してしまいそうだったら、別な問題を抱え
ているものです。「関数成長ホルモン不均衡症候群」というやつですから、
詳しくは次の章を見てください。
第４章：関数
関数は短くてかわいいいのが一番。欲張って色気を出しすぎてはいけませんよ。
関数は１画面か２画面に収まるようにします（ISO/ANSIの画面は80文字×24行
だというのは知ってるよね）。ひとつの関数はひとつの処理に専念して、それ
だけをキッチリと行いましょう。
許される関数の長さは、その関数の複雑さと関数内の字下げの深さに反比例し
ます。たとえば、単純な処理をする関数の中身が一つの長〜いswitch文だとし
ます。この場合、ちょっとした処理をするcaseの数が多いだけでそれぞれcase
が単純ならば全体が長くなっても良いでしょう。
しかし、複雑な処理をする関数があって、「平凡なプログラマ１年生には何を
やりたいのかさえ理解できないだろうな」と思ったら、わかりやすくするため
の対策をしっかりと打つべき。こういう場合には、わかりやすい名前の補助関
数を使ってみてください。関数呼出しにともなう処理速度低下が問題になると
思ったら、コンパイラにインライン展開してもらえばよいのです。多分あなた
自身で展開するよりもうまくやってくれますよ。
関数を測るもう一つの物差しは、ローカル変数の数。ローカル変数は５〜１０
個にとどめるべきで、それを越えるようだったら関数の設計自体に問題がある。
そういう時は関数の役割りを見直して中身を分割すべきです。人間の脳は７個
ぐらいまでの事を気軽に並行して扱えるけど、それ以上は混乱の元。あなたが
優秀なのはあなた自身が一番良く知っていますが、２週間前に書いたものがす
ぐに分かると嬉しいとは思いません？
第５章：コメント
コメントは役立つものだけど、コメントの付けすぎも危険なことを意識してく
ださい。けっして、コメントでプログラムの仕組みを説明しようとしてはいけ
ません。プログラムを見ただけで仕掛けがすぐに理解できるように書いた方が
遥かによいものです。分かりにくいプログラムに必死にコメントを付けるのは
時間の無駄ですよ〜。
普通コメントにはプログラムが何をしているかを書きたくなるものだけど、プ
ログラムの仕組みを説明しようとはしませんよね。それから、関数の本体内に
コメントを書くのはやめましょう。関数が複雑だから関数の中にコメントを書
く必要があると思ったのなら、第４章を読み直してください。それから、「極
めて巧妙なワザ（汚い手ともいう）を使ったよ」と注意したい時にはちょっと
したコメントを付けても良いですが、やりすぎないでください。まとめると、
「関数がどんな処理を何故するのかを伝えるようなコメントを関数の先頭に付
けよう」ということです。
第６章：醜くしちゃったら
大丈夫です。失敗は誰でもするものです。多分あなたも、長年UNIXの使い方を
アドバイスしているような先輩から「 GNU Emacsは自動的にＣのソースコード
を整形してくれるよ」と教わって自動整形を体験してしまったのでしょうねぇ。
残念ながら、Emacs のデフォルト設定はあまり好ましくいものではないんです。
（思い切って言うと、GNU Emacs の自動整形よりは適当にプログラムを書いた
方がまし。何万匹のサルが GNU Emacsに向かってプログラムを打ち込んでも、
まともなプログラムは決してできません。）
そこで選択肢は２つ。GNU Emacs を使うのをやめるか、もっと健全な設定にし
て使うかです。健全な設定にするには、ホームディレクトリの「.emacs」に次
の様な指示を入れておけばＯＫ：
(defun linux-c-mode ()
"C mode with adjusted defaults for use with the Linux kernel."
(interactive)
(c-mode)
(setq c-indent-level 8)
(setq c-brace-imaginary-offset 0)
(setq c-brace-offset -8)
(setq c-argdecl-indent 8)
(setq c-label-offset -8)
(setq c-continued-statement-offset 8)
(setq indent-tabs-mode nil)
(setq tab-width 8))
これで、M-x linux-c-mode コマンドが使えるようになる。モジュールのソー
スコードをいじるなら、先頭の２行のどこかに、「 -*- linux-c -*- 」とい
う文字列をいれておけば自動的に linux-c-mode になります。さらに凝って、
/usr/src/linux の中にあるソースコードファイルを修正する時には自動的に
このモードになるようにするなら、先程と同じ「.emacs」ファイルに、
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
auto-mode-alist))
と加えておけばＯＫです。
さらに、Emacsにまともな整形をさせそこなっても、まだ大丈夫です。indent
コマンドを使えば救われます。
ただ、GNU の indentもまた GNU Emacs と同様の病的なデフォルト設定になっ
ています。そこで、indentを使う場合にはコマンドラインオプションが必要に
なってしまうのです。それでも、まんざら捨てた物ではありません。GNU版の
indentを作った連中でも偉大なる K&R を無視してはいません（別に、GNUの連
中が悪魔だというつもりはありませんよ。連中は、Ｃプログラムの書式に関し
て派手に道を外してしまっただけ）。ですから、indent に「-kr -i8」という
オプションを付けるだけで良いのです。このオプションは、K&R に従って、字
下げ量(indentats)は８文字にしなさいという指示です。
実は indent コマンドには多数のオプションがるので、特にコメントを整形す
る方法に関してはマニュアルページを見ておくのが良いと思います。しかし、
「indentはプログラマーの悪い僻を直してはくれない」ということを忘れない
でくださいね。
Linux カーネル 2.2 付属文書一覧へ戻る