ここでは、リファクタリングの際に行っている作業を体系的（できるのか？）にまとめることで、コーディング開始時から行える開発規約の作成を目指します。
どの言語問わず（といっても自分が携わっているC#,VB.net,PL/SQL,等などの静的型付け言語向けかな）共通することをまとめます。
※なお、クライアントあぷりも、WEBアプリもひとくくりで書いているため、登場する単語がちぐはぐですが、今後統一予定です。
言葉の定義
以下、言語を特定せず使える規約を目指すため、極力抽象化した表現に留める。
必要に応じて定義をこの項に記述していく。
- 1コード
関数など言語により記述する1ファイルに納められる物
または クラスの1メソッドなど
コーディングの効率化
コーディング作業を効率化するために必要なルール
1コードは1画面に収める
基準は開発で使用しているIDEや、テキストエディタでスクロールしないで全体を見渡せること。
スクロールしながら、上に下に行ったり来たりしつつコードを読むのは大変。
記述料が多いと言うことは過剰に役割を与えすぎている。
処理分割して外出しにすること。
※「異なる目的を1コードで行っている関数の分割」参照
※データクラスなどテーブルとマッピングするような機能はこの限りではない。
多段ネストの禁止
ネストは最大2段まで（本当は1段にしたい）
2段を超えると極端に可読性が悪くなる上に、「1コードは1画面に収める」がしずらくなる。
どうしてもネストせざるを得ない場合はループブロックを外出しにする。
同じく三項演算子などのネストも禁止（これは絶対に1段）
ネストを深くしないために
インテリセンスの活用の為に
主に命名規約に関するものですが、いまどきのIDEは強力なインテリセンス機能を有している物がほとんどです。
インテリセンスはコーディングのリズムに大きく影響するので、自然な流れで使いたいオブジェクトなどを呼び出せる事が重要。
その為、名前だけで必要な情報にたどり着く命名規約を考える。
そして、皆同じルールで名前付けしないとこのリズムが大きく崩される。
「命名規約」参照
命名規約
命名規約と言っても「変数」の名前の付け方ではない（含まれるが）
プロジェクトを通して同じリズムでコーディングできる名前を体系立てて設定する
※長くなりそうなので、別コンテンツを設けます。
命名規約
無意味なコメントの禁止
「○○を変数に詰める」みたいなコメントは見れば分かる、むしろそのコメントを書かなければならないような読めないソースなのだとしたら論外。
「何年何月何日：～」そんなものはソース管理にまかせる。
いちいち残していたら可読性が悪い。
そのかわりソース管理にコミットするときに完結になにをしたかわかる様に
意味のあるコメントとは
- 「何のために」この処理を行っているのか
- やむを得ず複雑な処理で複数の関数、イベント等などを跨がって処理される場合の前後関係
- ソースを修正する際の注意事項
- 複雑なマトリクスを表現している場合などの設計書へのリンク
※ソースでは説明しきれない条件や情報は設計書があるべき
コードの構成
役割を混ぜない
一つのコードの中に異なる役割の記述をしない。
例えば複雑な登録のケースはFacadeパターンの様に、それぞれの役割を順に実行するだけの役割を作り、その中では処理を記述しなければ
情報は一箇所で管理する
ある情報から結果を導きたいときに、情報が散らばっているとどのタイイングで情報が変更されるのか特定し辛い。
これらを避けるために情報は一箇所で管理すべき。
例えば情報を管理するクラス(Model)を作成し、情報へのアクセスはこのクラスが提供するインターフェース(場合によってはViewModel)のみで行うこと。
ModelをつかったViewとのデータバインディングは便利だが、ViewからさらにAjaxやCallBack関数等で非同期に書き換えされる際などは、Modelを使用した処理タイミングに気をつけること。
むやみにフラグをつかった制御はしない
フラグを使うことはやむを得ないが、不用意にフラグを増やさない。
フラグがOn/Offの2値だとしても、一つ増やす度にフラグの組み合わせはx2で増えていくと心得ること。
フラグ1つで2パターン
フラグ2つで4パターン
フラグ3つで8パターン
：
フラグ10で1024パターン！
フラグを立てる場所は複数でも、制御は1箇所で
フラグを立てたイベントの中で画面制御をしない。
画面の状態を管理するモデルにフラグの状態を管理し、フラグの組み合わせなどでどのように制御するかは、1箇所（1メソッド）で完結させる。
これによって、画面制御に不具合が生じた場合は画面状態制御モデルだけ注視すれば良くなる。
コードの整理
基本的にボーイスカウトルールの徹底です。
条件が3つ以上になったら判定関数にする
((A And B) OR C)くらいの条件だったらまだ読めるが、判定条件が4つも5つもあると、何をどんな理由で判定しているのか分からなくなってくる。
また、条件文の途中にコメントも記述し辛い。
判定関数にすれば条件を分解して、早期リターンで結果を返せる。
また、関数の中に判定の意味をコメントする事もできる。
判定関数は命名規約にしたがって、統一する。
同じ事(似た事)を行っている関数の統合
「命名規約」をきちんと守っていくと、同じ様な関数の存在に気づくことが出来る。
その場合関数をどちらかに統合して、片方の関数をObsolate扱いにして統合していく。
※似た役割ならインターフェースも同じであることが多い。
異なる目的を1コーデ行っている関数の分割
関数名を付けるとき一つの役割に絞れないような関数は、複数の役割が一つになってしまっている場合があるので分割する。
いまどきのIDEなら、いくつに分割しようが対象のコードにジャンプする機能はあるので問題ない。
不要な変数はちゃんと整理して消す
使ってないのに変数定義が残っていると、どこで使われているのか探さないと行けなくなる。
上の「1コードは1画面に収める」などして不要になった変数はちゃんと消す。
作業過程で作ってしまった変数などは消す。
意外としていない人が多い。
不要なコメントの削除/訂正
「無意味なコメントの禁止」の様なプログラマを惑わすコメントは削除して、必要に応じて後から他の人が見ても分かるコメントに置き換える。