私的なメモです。自分以外の人にとってはあまり役に立たないと思います。 メモというより独り言になっている部分もありますが、今更編集しなおすのも辛いので軽くスルーしてください。 また、同じような内容が繰り返し記述されている可能性もありますが、まとめる気力がないのでスルーしてください。
現在ナッシングです。
出力メッセージ用の文字定数は文言中に改行および置換文字を含めるようにしておき、メッセージ出力用共通関数を用意して、 その関数内で置換文字の置換や改行の適切な変換（Winの時はCrLf、DHTMLのJavaScriptの時は\nなど）を自動で行うようにすれば使いやすいと思う。
関数のコメントヘッダなどを記述する時は
/*-------------------------*/
/*-- ほにゃらら --*/
/*-------------------------*/
'****************************
'** ほにゃらら **
'****************************
のようにハイフンとかで説明を囲んだりしない。これを綺麗にやっていこうとすると、 「ほにゃらら」の部分の長さが変わる度に、くずれたコメントのレイアウトを直さなくちゃいけなくなる。
たぶん・・・使用する区分値が区分値自体に意味を持っている場合はDBじゃなくてプログラム上で定数とかで定義すべき。 区分値自体に意味を持っていない場合（都道府県名とか）は、名称マスタで管理したほうが良いと思う。
各人の環境によって（定数値などの）設定を変えるファイルは、それ専用の環境設定ファイルを別に用意する。 そうしないと、最新のファイルを取得したら自分用にカスタマイズしていた環境設定も元に戻ったりしてしまうので、更新がめんどくさくなる。
関数内でUI操作（メッセージボックス表示など）を伴うような共通関数の作成は、（関数の目的にもよるが）できる限り避けるべき。 どうしても共通関数内でUIを処理したい場合は、UIを処理しない純粋な共通関数と、 それを利用してUIも処理するラップ関数を作成したほうが後々便利だと思う。
システム全体としてのエラー戦略を、コーディングに入る前に決めておくこと。
今まで見てきた限りだと
・画面初期化時のエラーなど正常処理続行不可能なエラーが発生
→エラー画面に遷移し、処理続行不可能とする
・何かのボタンを押したとかのタイミングで発生したアクションで、エラー発生
→基本的にはエラーメッセージを表示した後、エラーが発生したアクションが起こる前（ボタンが押される前）の状態に戻し、処理続行を可能とする。
処理続行が不可能なエラーが発生した場合、エラー画面へ遷移（WEBアプリの場合）し処理続行不可能とする。
が多かった。上記いずれの場合も、エラーの詳細内容をログに吐いておく必要がある。
この辺りの処理は出来る限り共通化しておかないと、各エラー箇所での記述量やメンテナンス量が増えて大変になるかも。
Configなどにフォルダのパスなどを設定する場合、パスの最後の"\"記号は付加しない記述方法に統一したほうが分かりやすいと思う。 一応、パスの後ろに"\"がない時は自動で付加する共通関数を用意しておいて、 プログラムでは必要に応じてその関数を通すようにすれば間違って"\"が付加されてる場合もあまり問題が大きくならない。 .NETの場合はPathクラスのCombineメソッドを使う手もある。
信頼できない外部からの入力値（Config設定値など）については、取得した時点で検証可能なチェックを全て行うべき。 そうすることで、変数に格納されている値が不正な状態でないことを前提にコーディングすることができる。 DBとか、比較的信頼できる（自アプリケーションが設定した値など）値については、もちろん（？）チェックする必要はない。 これがおかしかったら単純に自アプリケーションのバグなので。
httpのリクエストにプロキシを使用する場合、DNSによる名前解決もプロキシサーバー側で処理し、 クライアント側では名前解決も行わないっぽい（hosts設定も使用されない）。 ただ、もちろんプロキシサーバー自体の名前解決はクライアントで行わなければならない。
「Process Explorer」というソフトで分かる。
ツールバーの[Find] - [Find Handle]を開き、調べたいファイル名を入れればそのファイルをつかんでいるプログラム名が表示される。
SQL書く時は、処理するカラムが多い時とかはテーブル定義からカラム情報をコピーして、 正規表現とかで置換してある程度のテンプレートを作成すると、楽。 その際、カラムの属性とかも判断して属性にあった共通メソッドとかも記述されると、更に楽。 この方法使うと、（当たり前だけど）カラム名の打ち間違いとかがなくなるし、 自力でコーディングする時にめんどくさいカラムの日本語名とかも（やろうと思えば）全部コメントで記述できる。
区分値や共通で使用するであろう定数は、必ず定数化するべき。 レベルも、システム共通、サブシステム共通、画面ごとぐらいのレベルで用意しておいて、実装の仕方も使い方も全て同じにする。 同じ仕組みにしておけば、例えばサブシステム共通で使用していた定数をシステム共通の定数クラスに移動する必要があった場合も、 最小限の手間で済む気がする。 まずは、しかるべき場所に例え定数の定義がないとしても定数用のクラスを作成するようにした方が良いと思う。 人間的な話になってしまうが、そういうのが事前に存在していれば定数を定義する必要があった時にその場で定義する気持ちが出てくると思う。 また、例えその定数クラスに定数が1つも定義されていなかったとしても、 それは逆にそのレベルで使用している定数は1つもないと言う事が明示的にわかるので（あまりそういう事はないとは思うけど）、 それはそれでそれなりのメリットになると思う。 まあ、ここまで書いておいてこんなこと言うのも何だけど、 実際に仕事で上記のようにやったことはこれまでないので現実性がどれだけあるかは不明。
色の組み合わせとかについて色々と有用な事が書いてある。
テーブル設計はもちろんだが、プログラム側も色々と対処する必要がある。 セッションやビューステートに大量のデータを保持しないようにしたりするのはもちろんだが、 例えばSELECT前に必ずCOUNTで取得件数を確認するとか、そういうことも含めてトータル的に考えないといけない。