1. Title
OSS のコーディングスタイル
たなかとしひさ
tosihisa@netfort.gr.jp
1

2. 始めに･･･
■ このドキュメントは LGPL ライセンスです。
■ 何でって･･･このスライドのテンプレートが LGPL なもんで…
http://ooextras.sourceforge.net/downloads/simpress/
2

3. ライセンスはさておき･･･お題目
■ 「コーディングスタイル」って何よ？
■ それが OSS と、どう関係あるのさ？
■ いくつかの OSS コーディングスタイルを見てみる。
■ 頭の中でグルグルと考えてみる。
■ まとめ
3

4. コーディングスタイルって何よ？
■ CodingStyle...
■ プログラムを記述する上での規約、取決め、掟 (!) をまとめたものです。
■ 例えば…
int main(void)
{
printf(“hogen”);
return 0;
}
と書くか…あるいは、
int
main(void)
{
printf(“hogen”);
return 0;
}
と書くかを決めるものですね。
4

5. それが OSS と、どう関係あるのさ？
■ 関係あるあるって。
■ 例えばさ…
パッチ作成者 メンテナ
func( ) のパッチ書いたよ。 ありがとー。反映するっす。
タブサイズ４で、
漢字コードは EUC ね。
あ、行末は UNIX 改行ね。
これだけならイイケド…
5

6. これでもイイのカナ？
■ オレはイヤダ･･･
func( ) のパッチ書いたよ。
タブサイズ 8 で、
漢字コードは JIS ね。
行末？ UNIX っすよ。当然。
func( ) のパッチ書いたよ。
タブサイズ４で、
漢字コードは EUC ね。
あ、行末は UNIX 改行ね。
func( ) のパッチ書いたよ。
タブサイズ 2 で、
漢字コードは UTF-8 ね。
func( ) のパッチ書いたよ。 行末？分かんないよ。
タブサイズ８で、
漢字コードは SJIS ね。
あ、行末は DOS 改行ね。
6

7. メンテナさんは…
■ もちろん、パッチは歓迎。
■ とは言え、みんな各々の「オレ様スタイル」だと、プログラムは動いたとし
ても後々保守しづらいものになります…。
真面目な話、コーディングスタイルは、ぶっちゃけ何でも
良いですが、統一性の無いスタイルのソースは、マジで読
みにくいっす。
スタイルは何でもイイですけど、ソース内での統一性は重
要です。
7

8. いくつかの OSS コーディングスタイルを見てみる
■ GNU コーディング標準
■ Linux カーネル コーディングスタイル
■ gawk コーディングスタイル
■ UBoot コーディングスタイル
■ OOo コーディング標準
■ わかりやすいコードを作成するための 6 つの方法
8

9. GNU コーディングスタイル
■ GNU Coding Standards
■ 出展：
http://www.sra.co.jp/wingnut/standards-j_toc.html
■ 単なる「規約」のみならず、プログラム設計のアドバイスからドキュメント
の書き方まで書いてある。
↓以下、その抜粋。
■ カラム０に関数本体の始まりの開き括弧を置くことが大事です .
■ 関数定義において , 関数名をカラム０から始めることも大事です .
他の人が関数定義を検索するのに役立つし , ツールが関数定義を認
識するのにも助けになります .
static char *
concat (char *s1, char *s2)
{
...
}
■ 整数の定数を定義したかったら #define より enum を使いましょう .
GDB が enum 定数を理解するからです .
9

10. Linux カーネルコーディングスタイル
■ Documentation/CodingStyle
■ 出展：
http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html
■ First off, I'd suggest printing out a copy of the GNU coding standards,and
NOT read it. Burn them, it's a great symbolic gesture.
■ まず最初に、「 GNU コーディング規約」 (GNU coding standards) を入手して印
刷してみてください。でも、読むために印刷するのではありません。印刷した物
を燃やすのです。この儀式は晴れがましい意思表示なのです。
■ タブは８文字です。なので、インデントも８文字です。
■ コメントやドキュメーテンション以外では、決して空白でインデントしてはいけま
せん（ただし Kconfig ファイルを除く）。
■ まともなエディタを使ってください、そして行の最後に空白文字を置かないでく
ださい。
■ 行の長さは８０カラムが限界で、これは絶対条件です。
■ 関数の型を関数名に含める方式（いわゆるハンガリー記法）は、明らかに間
違っています。そんなことをしなくても、とにかくコンパイラは型を知っています
し、型のチェックもできます。結局はプログラマ自身を混乱させるだけです。
Microsoft がバグの多いプログラムを作っているのも不思議ではありません。
■ goto 構文の利用に否定的な人もいますが、コンパイラは goto 構文に等しい
無条件 jump 命令を頻繁に出力しているのです。
■ マクロは大文字が好ましいですが、関数形式マクロは小文字でも構いません。
10

11. gawk コーディングスタイル
■ 出展：
http://www.kt.rim.or.jp/~kbk/gawk-30/gawk_21.html
■ GNU Coding Standards に従う。
■ gawk のスタイルを使用する。 gawk の C ソースコードは GNU Coding
Standards に従っているが、幾つかの小さな例外がある。ソースコードの
フォーマットは ( 特にブレースの位置について )"K&R" スタイルを使用し
ており、タブを使っている。
■ 多重の副作用を作り出すためにカンマ演算子を使わないこと。ただし、
for ループの初期化部分や、 incremnt part 、マクロの本体は除く。
■ インデントにはタブコードを使い、スペースを使わない。
■ `#elif' を使わない。 UNIX 上で動作する多くの古い C コンパイラはこれ
を扱うことができない。
■ スタックからメモリーを割り付ける関数である alloca を使わない。これを
使用することによって、 ( 割り付けた領域を陽に free しなくても良いとい
う ) ちょっとした利益を受けるよりも重大なトラブルが引き起こされる。
alloca の代わりに、 malloc と free を使うように。
11

12. UBoot コーディングスタイル
■ 出展：
http://www.denx.de/wiki/UBoot/CodingStyle
■ C++ の '//' コメントは使わないで下さい。
■ 行末の空白は取り除いてください。
■ インデントには TAB(0x09) コードを使い、スペースは使わないで下さ
い。
■ MS-DOS の 'rn'(0x0d,0x0a) 改行は使わないで下さい。
■ ２行以上の空行を入れないで下さい。
■ ソースコードファイルの行末に空行を入れないで下さい。
12

13. OOo コーディング標準
■ http://wiki.services.openoffice.org/wiki/Coding_Standards
■ 英語。誰かヤク ^H^H 訳を～ ( 汗
13

14. わかりやすいコードを作成するための 6 つの方法
■ 出展：
http://www-06.ibm.com/jp/developerworks/linux/library/l-clear-code/index.shtml
■ ヒント 1: 賢い人にならってコメントを付けること
■ ヒント 2: #define をたくさん使うこと。ただしやたらに使うのは禁物です
■ ヒント 3: わかりにくい変数名を使わないこと
■ ヒント 4: エラー・チェックを行うこと。誰にだって間違いはあります
■ ヒント 5:
「 Premature optimization is the root of all evil
( 早まった最適化は諸悪の根源である ) 」 - Donald Knuth
■ ヒント 6: あまりにも賢くなりすぎないこと
14

15. 頭の中でグルグルと考えてみる。
■ インデントに使う TAB は 0x09(TAB コード ) を使うべきか 0x20( スペー
ス ) を使うべきか？
■ http://blog.livedoor.jp/dankogai/archives/50475459.html
に興味深い記述がある。
■ patch コマンドでパッチをあてる場合、インデントに 0x20( スペース ) を使
う方がつぶしがきく。
→コピペした場合、 0x09 は 0x20 に置き換わり、 TAB 文字だったのか
スペースだったのか分からなくなる。
15

16. 共通項をまとめると･･･
■ 1 行は 80 文字以内。
■ タブはタブコードを使い、スペースは使わない。
■ 行の最後にスペース ( 空白 ) を入れない。
■ goto の使用は禁じていない。
もっとサンプリングする必要アリ・・・
16

17. まとめ
■ 各々のコーディングスタイルを読むと分かりますが、単なる自己満足で
はなく、それを策定するに当たり、何らかの背景があります。
■ その背景を知る事で、バグを生みにくいコーディングを心がけるようにな
ると思います。
■ すなわち、コーディングスタイルは、単なるお仕着せではなく、先人の知
恵の重なり、すなわちノウハウを一つの形にしたものです。
■ プログラムを書き始めて経験が浅い方は、ぜひ一度、色々なコーディン
グ規約を読んで、自らの知識への糧として下さい。
17