コーディングの際に「やっていること・やるべきこと」のまとめ（β版）
コーディングの際に、知っておくべき情報や注意してる点など、
やっていること・やるべきことを自分なりにまとめてみました。
ただし、（おそらく永遠の）ベータ版です！
- クラス名、メソッド名、変数名などの名前付けにこだわる。
変数名へのこだわりの無さが「バグの温床」になることを理解する。
- コーディングスタイルは無数にある。重要なのは、自分のスタイルを貫くことではなく、１つの決めたスタイルに合わせることである。
- NullPointerExceptionがでないかどうかに神経を使う
パラメータ引数がnull だったら、戻り値がnullだったらを常に問う。
- コメントは適度に付ける。多すぎても、少なすぎてもいけない。
自分じゃない人がコードをメンテナンスする際に困らないように気を配る。
- 自分が理解できないコードを書かない。
- 例：内容は理解していないがコピー＆ペーストしたコードを少し修正しただけでとりあえずＯＫなどと考えるのはＮＧ。
⇒ ＮＧな理由
(1) 責任を放棄している
(2) DRY原則に違反している
(3) コピー＆ペーストしたコードに不適切なコードが紛れているかも知れない
- １つのメソッドに多くの責務を詰め込まない
- １メソッド内の行数が多すぎると何かおかしいと思うべき
- メソッドの引数が多すぎる時は、パラメータの入れ物クラスを作成する
- if文の条件判定部分が複雑になる場合は、別メソッドにする
- １つのクラス内でメソッドを配置する位置にルールを持たせる
例えば、アクセッサメソッド群、privateメソッド群、publicメソッド群の順番で書く。
- 横に長すぎるソースコードを書かない
読みやすいようにソースコードを整形しよう。
- 正常系ロジックの可読性が向上するように注意を払う
例えば、複数のエラーチェックロジックの後に正常系処理を記述する。
エラーチェックロジックでエラーになった場合は、return 文を使って制御するのが基本。
(return文を使わないと、ifブロックのネストが深くなってしまう)
もしくは、try 〜 catch を使って、正常系コードと異常系コードを分離する。
- try 〜 catch を使う場合に、close処理など途中で例外が発生した場合でも呼ばなければならないような処理はfinally句に書くこと
- パッケージ及びモジュールが相互依存しないようにする。
- メンバー間でお互いのソースコードをレビューしあう
特に、ソースコードの書き始めはこのレビューは重要。
- 業務ロジックはできるだけステートレスなメソッドで記述する
実装では「ステート」はインスタンス変数を指す。
ステートレスなメソッドとは、パラメータ引数だけで、戻り値が一意に決まるメソッド。
逆に、ステートフルなメソッドとは、パラメータ引数とインスタンス変数で戻り値が一意に決まるメソッド。
ステートレスなメソッドの方がシンプルでテストがしやすい。
- 変数のスコープ（使用可能な場所の範囲）はできるだけ小さくする
- インスタンス変数よりもローカル変数
- （常にメソッドの開始直後ではなく）必要な処理の直前で変数を宣言する
- 独りよがりのエラーメッセージにならないように、他のメンバーに分かりやすいかを確認してもらう
（エラーメッセージ一覧は後でまとめてチェックする。）
- いくつかの処理の塊に名前をつけることができるなら、別メソッドに切り出すべし。
- 行き当たりばったりにコードを書くのではなく、先にメソッドの枠を書いておき、後で中身を埋める。
- プロジェクトごとのローカルコーディングルールの理解を深める。
-
-
- -
-
振り返って思うに、ある程度の力量の人には特に目新しいことは無いだろうし、
逆に初心者の人には（抽象度が高くてサンプルコードが無いため）何のことだか分からない記述になってしまった。
※ 『WEB+DB PRESS Vol.33 の構造化プログラミング入門』の記事を少し参考にしました。
