[参考スタイル]

・Internet
動くコード(Running Code)に重きを置く
・XP(eXtream Programming)
　　　計画よりも軌道修正に重きを置く
・Agile
　　　コード自体が設計


[開発スタイル]

　・コードは素早くcommitする
完璧な単体テストをしてからコードを(CVSに)commitするよりも、どんどんcommitして、みんなでテスト、コードレビューをしてバグを見つけていきます。
他人にバグを指摘されることを恐れたり、恥ずかしがらないでください。 バグを見つけてもらってラッキー、ぐらいに感じてください。
当然ながら、単体テストをしない、という意味ではありません。 commit前に簡単な動作チェックやコンパイルが通ることを確認するのは、開発者の常識の範囲です。いつまでもコードを公開しないでいるよりは、バグが見つかってもいいから、早く手放せ、という意味です。

　・バグは責めない
「バグはあって当然」です。「バグがあることを前提」にして全て(の開発工程)を考えています。バグのあるコードを書くことに、一切のマイナス評価はしません。バグがあることを前提にしているので、「バグをいかに見つけるか」がキーポイントです。バグを作ることは問題ではなく、バグを見つけられないことが問題です。
アリエルネットワークでは、開発者全員が常にテストをするので、バグのある製品を出荷した場合、バグを見つけられなかった全員に非があります。

　・書き直しを恐れない
ソースコードの書き直しを恐れないでください。 動いているコードに手をつけるな、という格言があります。 時と場合によっては真ですが、そうでは無い時もあります。 保守できない(読めない、理解できない)ソースコードなら、思い切って捨てる勇気を持ってください。

　・ソースコード自体を記述的に
ラフな仕様(設計)と合意は重要ですが(メディアはローテクで良いです。紙とホワイトボードとミーティング。
AirOneでミーティング結果をポストしてください)、内部スペックを自然言語で書くぐらいなら、コード自体を記述的(descriptive)にしてください。
　　※テクニカルノート
コード自体が記述的というのは、コメントを沢山書くという意味ではありません。ロジックに関して言えば、コメント不要のシンプルなコードが良いです。データ構造(構造体やクラス定義)が記述的であることが、ロジックが記述的であることよりも重要です。
パブリックなヘッダファイルとプライベートなヘッダファイルの区別を意識しましょう。パブリックなヘッダファイルはそれ自体が内部スペックです。
結局、保守するのはソースコードです。中間生成物(昔ならフローチャート。最近だとUMLなど)は少なければ少ないほど良いです。

　・結局はコミュニケーション
あまりに単純なバグが頻発すると腹が立ってきます。 汚いソースコードを見ると気分が悪くなります。
開発者の間のコミュニケーションがとれていないと、バグを見つけても、まあいいかとなってしまいますし、汚いコードは見て見ぬふりになってしまいます。コミュニケーションが良好であれば、バグを見つければ、それぐらい直せばいい、となりますし、汚いコードを見れば、そんなの書き直せばいい、という気分になります。