Oss coding style
-
Upload
toshihisa-tanaka -
Category
Documents
-
view
412 -
download
0
Transcript of Oss coding style
2
始めに・・・
■ このドキュメントは LGPL ライセンスです。■ 何でって・・・このスライドのテンプレートが LGPL なもんで…http://ooextras.sourceforge.net/downloads/simpress/
3
ライセンスはさておき・・・お題目
■ 「コーディングスタイル」って何よ?■ それが OSS と、どう関係あるのさ?■ いくつかの OSS コーディングスタイルを見てみる。■ 頭の中でグルグルと考えてみる。■ まとめ
4
コーディングスタイルって何よ?
■ CodingStyle...■ プログラムを記述する上での規約、取決め、掟 (!) をまとめたものです。■ 例えば…
と書くか…あるいは、
と書くかを決めるものですね。
int main(void){ printf(“hoge\n”); return 0;}
intmain(void){ printf(“hoge\n”); return 0;}
5
それが OSS と、どう関係あるのさ?
■ 関係あるあるって。■ 例えばさ…
func( ) のパッチ書いたよ。タブサイズ4で、漢字コードは EUC ね。あ、行末は UNIX 改行ね。
パッチ作成者 メンテナ
ありがとー。反映するっす。
これだけならイイケド…
6
これでもイイのカナ?
■ オレはイヤダ・・・
func( ) のパッチ書いたよ。タブサイズ8で、漢字コードは SJIS ね。あ、行末は DOS 改行ね。
func( ) のパッチ書いたよ。タブサイズ4で、漢字コードは EUC ね。あ、行末は UNIX 改行ね。
func( ) のパッチ書いたよ。タブサイズ 2 で、漢字コードは UTF-8 ね。行末?分かんないよ。
func( ) のパッチ書いたよ。タブサイズ 8 で、漢字コードは JIS ね。行末? UNIX っすよ。当然。
7
メンテナさんは…
■ もちろん、パッチは歓迎。■ とは言え、みんな各々の「オレ様スタイル」だと、プログラムは動いたとし
ても後々保守しづらいものになります…。
真面目な話、コーディングスタイルは、ぶっちゃけ何でも良いですが、統一性の無いスタイルのソースは、マジで読みにくいっす。
スタイルは何でもイイですけど、ソース内での統一性は重要です。
8
いくつかの OSS コーディングスタイルを見てみる
■ GNU コーディング標準■ Linux カーネル コーディングスタイル■ gawk コーディングスタイル■ UBoot コーディングスタイル■ OOo コーディング標準■ わかりやすいコードを作成するための 6 つの方法
9
GNU コーディングスタイル
■ GNU Coding Standards■ 出展:
http://www.sra.co.jp/wingnut/standards-j_toc.html■ 単なる「規約」のみならず、プログラム設計のアドバイスからドキュメント
の書き方まで書いてある。↓以下、その抜粋。
■ カラム0に関数本体の始まりの開き括弧を置くことが大事です .■ 関数定義において , 関数名をカラム0から始めることも大事です .
他の人が関数定義を検索するのに役立つし , ツールが関数定義を認
識するのにも助けになります .
■ 整数の定数を定義したかったら #define より enum を使いましょう . GDB が enum 定数を理解するからです .
static char *concat (char *s1, char *s2){ ...}
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) を入手して印刷してみてください。でも、読むために印刷するのではありません。印刷した物を燃やすのです。この儀式は晴れがましい意思表示なのです。
■ タブは8文字です。なので、インデントも8文字です。■ コメントやドキュメーテンション以外では、決して空白でインデントしてはいけません(ただし Kconfig ファイルを除く)。
■ まともなエディタを使ってください、そして行の最後に空白文字を置かないでください。
■ 行の長さは80カラムが限界で、これは絶対条件です。■ 関数の型を関数名に含める方式(いわゆるハンガリー記法)は、明らかに間違っています。そんなことをしなくても、とにかくコンパイラは型を知っていますし、型のチェックもできます。結局はプログラマ自身を混乱させるだけです。Microsoft がバグの多いプログラムを作っているのも不思議ではありません。
■ goto 構文の利用に否定的な人もいますが、コンパイラは goto 構文に等しい無条件 jump 命令を頻繁に出力しているのです。
■ マクロは大文字が好ましいですが、関数形式マクロは小文字でも構いません。
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 を使うように。
12
UBoot コーディングスタイル
■ 出展:http://www.denx.de/wiki/UBoot/CodingStyle
■ C++ の '//' コメントは使わないで下さい。■ 行末の空白は取り除いてください。■ インデントには TAB(0x09) コードを使い、スペースは使わないで下さ
い。■ MS-DOS の '\r\n'(0x0d,0x0a) 改行は使わないで下さい。■ 2行以上の空行を入れないで下さい。■ ソースコードファイルの行末に空行を入れないで下さい。
13
OOo コーディング標準
■ http://wiki.services.openoffice.org/wiki/Coding_Standards■ 英語。誰かヤク ^H^H訳を~ (汗
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: あまりにも賢くなりすぎないこと
15
頭の中でグルグルと考えてみる。
■ インデントに使う TAB は 0x09(TAB コード ) を使うべきか 0x20( スペース ) を使うべきか?
■ http://blog.livedoor.jp/dankogai/archives/50475459.htmlに興味深い記述がある。
■ patch コマンドでパッチをあてる場合、インデントに 0x20( スペース ) を使う方がつぶしがきく。→コピペした場合、 0x09 は 0x20 に置き換わり、 TAB文字だったのかスペースだったのか分からなくなる。
16
共通項をまとめると・・・
■ 1行は 80文字以内。■ タブはタブコードを使い、スペースは使わない。■ 行の最後にスペース (空白 ) を入れない。■ goto の使用は禁じていない。
もっとサンプリングする必要アリ・・・