プログラミングのルール

自分のルールを twitter に書いてみました。1時間半ぐらいやってたらしい。

＊　＊　＊

変数名やクラス名に省略した単語でなく正しいスペルのものを使う。

他人のインデントはいじらないが、間違ってるのはなおす。同じインデントシステムを使う。勝手に発明しない。ちなみに、K&R

大域変数は使わない。Singleton も使わない。インスタンス変数経由でパラメータを渡さない。必要な場合のみに使う。

コメントは関数/メソッドの役割に対しておこなう。bug fix comment には例を含める。

測定を伴わない最適化は無意味で間違っている。

xUnit を使う。

修正前のコードを残すようなことはせず、版管理にまかせる。

fprint() ; exit() ; のようなエラー処理をせず、エラー処理ルーチンを呼ぶ。

malloc を裸で使わない。

use case 図から書き始める。

if else if else を使い、条件を複雑にしない

Java は IDE を使い、ant/maven をつける。Eclipse 派です。

Warning はすべて取る。

変数宣言は使う直前に行い、局所変数は宣言と初期化を同時に行う。

コメントは英語

Java のdefault package は使わず、必ず、独自の package をはさむ。

関数、メソッドは、一画面に収める 。大きな画面なら大きくして良い。

怪しい優先順位には()を多用する。

可能な限り関数的にプログラミングする。副作用を避け、変数の再利用をしない。

寿命の短い変数は、i とか j とかでよい。

短いメソッド名を使わない。メソッド名は再利用する。

継承よりも interface を使う。

一つしか実装がないものを interface 化しない

最初からデザインパターンを目指さない。有効な時に refactoring で入れる。fly weight とかの例外はあるけど。

テストは自動化する

テストパターンは生成する

カバレッジを測定する

同じものを二度書かない。コピぺしない。

行き詰まった時に同じことを繰り返さない。方法が間違っている。

使用するAPIをテストする小さいプログラムをたくさん書く。思い込みでAPIを使わない。

API のエラーはチェックする。

malloc() のエラーチェックがあるのはプログラムの構造的な間違い。

もっとシンプルにならないかと考える。

データやオブジェクトを表示するルーチンを書く

長い時間プログラミングしない

コードレビューをする

こういうことをすると、favstar があふれるな… blog でやった方が良いか。

Iterator を使う。Iterator を書く。

Thread は基本的な同期構造と終了を PathFinder でチェックする (できるといいな、ぐらい)

プログラミング作法、達人プログラマー、そして、コードコンプリートを読む

gdb や Eclipse のデバッガに精通する。条件付きブレークポイント、変数監視を使う。

コンパイラが信用できない時にはアセンブラを見る

malloc にバグなし。malloc library のデバッガ、メモリリークツールを使う。

Java では object を使い捨てる。参照を長く維持しない。できるだけ早く捨てる。(C/C++とは違う)

寿命の長いデータ/オブジェクトはDBに入れる。

DBのテーブルには、id と key がある。

UMLのシーケンス図、協調図を使う。図を勝手に発明しない。

Cでは、include/定数宣言/変数宣言/関数先行定義/関数定義。extern を.c に書くのは手抜き。extern しない関数には static をつける。

エラー処理を分散しない。エラー処理ルーチンを呼ぶ。

file open に失敗した時は file name を表示する。

構造体は typedef し、PTR 型も用意する。* を宣言に使わない。malloc を個別に書かない。

局所変数のアドレスを取らない。(参照ならよいとは、僕は思わない。Effective C++ は違うのだが)

新しいことを勉強し続ける。自分で試す。

勉強会に参加する、自分で企画する。

一週間でできないものは方法論が間違っている。

Java のGeneric を複雑にしない

コンストラクタで複雑なことをしない。初期化を別に分ける。複雑な初期化を持つオブジェクトはファクトリーを用意する。コンストラクタをたくさん作ったりしない。

どんどん分割する。GUI をわける。

関わったプログラムのソースコードは、とりあえず全部目を通す。部分的に読んですませない。

GNU global などと reference 系よりも gdb で追った方が早い。deamon には、外から attach する。

gdb --args を使う。make に書いておく。.gdbinit を使う。

gcc は、もうだめ。clang を使う。

gdb は -O0 。最適化した時だけバグが出る時は、アセンブラから引数の値を見る。gdb から表示ルーチンを call する。

ByteBuffer? flip() したか? 理解してないなら、簡単なテストルーチンを書いて、position, limit, mark を確認

gdb は b main から。実行してC-Cで停めて where。up/down で break するところを探す。comm/cond を使う。ソースコードに if を入れると高速化できる。

hgは細かく commit する。どんどん push する。動いている版は tag をつける。multi head を恐れない。multi head を放置しない。

repository に入ってないソースは消滅する。

計算量を意識する。O(n^2)は実用的ではない。O(n)をn回繰り返すのはだめ。一方、O(2^n)でもnが小さいなら使える。

そろそろ尽きたか。Prolog篇、Perl篇、アセンブラ篇とかも、やりたい気もする。全然、尽きないじゃん…

Know How をwiki などで共有する。自分の中に閉じ込めない。

ペアプログラミングで教えた後「wikiに書いておいてね」と言うのが得意です。