戻る

Simple, Open, Share

Home
トップページ 会社案内 Javaコーディング標準 開発系メモ Q&A

7、その他

(72) 自分で新しく作る前に相談

他人が作成したクラスに対するある操作が新たに必要となるとき,
自分でそのクラスをextendsして新たなクラスを作成したり,そのクラスをインスタンス変数として持つクラスを作成するより,まずそのクラスの作成者に相談すること.
汎用的な形でその要望を満たしてくれれば,全体をコンパクトにできる.

(73) 複雑な設計は悪

設計で迷った場合,多くのケースは ‘Simplicity’ を重視した方が,java言語の特性と良く合う.
java言語の設計原理はKISS(Keep It Small and Simple)である.
また,後のメンテナビリティにも ‘Simplicity’ は重要である.

(74) パフォーマンス調整は測定後

最初からパフォーマンスを気にしたコーディングをするべきではない.
読みやすさ,保守のしやすさを優先する.
パフォーマンスは測定してから改善する.

(75) トリッキーなコードは悪

Javaの平均プログラマに分かるようなコードを書く.

演算子の順序,初期化に関する規則など,誰もが必ずしも自信をもって答えられないような仮定を持ち込まず,
() を使って演算順序を明確にしたり,明示的な初期化を行った方が読みやすい.

悪い例:
return cond == 0 ? a < b && b < c : d == 1;

良い例:
return (cond == 0) ? ((a < b) && (b < c)) : (d == 1);

悪い例:

// 単位行列を作るが,時間もかかるし誰も読めない.
for (int i = 1; i <= N; i++)
for (int j = 1; j <= N; j++)
M[i-1][j-1] = (i/j)* (j/i);

(76) 100%正しいことはない

ここに書かれていることに,100% 準拠する必要はない.
迷ったら考えを整理し,相談すること.
十分な理由があってルールから外れることはよくある.
コミュニケーションができるチームの助けとなることが,このコーディング標準の目的である.

©2014 Powered by 株式会社開成