| 開発規約/108 | 設計 | 拡張性のある外部データ構造の設計 |
| 開発規約/143 | Java | StringTokenizer を安易に使わない |
| 開発規約/33 | コーディング | 引数の順序について |
| 開発規約/123 | 設計、UI | 属性は、メニューでしか操作できないよりは、ダイアログでも操作できるようにする。 |
| 開発規約/96 | コーディング | 「ポインタは32bitである」という仮定をしないこと |
| 開発規約/52 | 設計 | メールアプリケーション作成時注意点 |
| 開発規約/12 | 品質 | 品質とは何か |
| 開発規約/129 | 設計 | DI コンテナとアスペクト指向(AOP)の採用について |
| 開発規約/113 | 設計、運用 | チューニング、パフォーマンス改善 |
| 開発規約/118 | 設計 | フォントについて |
| 開発規約/82 | 設計,コーディング | 変数初期化時に安易に空インスタンスを代入しない。 |
| 開発規約/135 | 設計、コーディング | ダウンキャストを避ける |
| 開発規約/17 | 基本 | 会議、打ち合わせでは必ずメモを取る。メモを出席者に渡して確認する。 |
| 開発規約/48 | コーディング | IPアドレスの直書きを避ける |
| 開発規約/139 | 構成管理 | 開発環境を単体環境と結合環境とに分ける |
| 開発規約/100 | 命名法 | 標準的なローマ字 |
| 開発規約/95 | コーディング | テキストモードとバイナリモードの区別を明確にする。(改行コードの取り扱い) |
| 開発規約/66 | HTML | 複数のボタンの判断はname側で行う。value側は使わない。 |
| 開発規約/154 | コーディング | 無理にクエリ1発でデータが取り出せるSQLを書かない。 |
| 開発規約/126 | 設計 | データベース設計アンチパターン |
| 開発規約/175 | [category] | [title] |
| 開発規約/120 | 設計 | 運用上起こり得る障害について |
| 開発規約/168 | 構成管理 | 使用したファイルは sha1sum を取って2ヵ所以上の場所に保管する |
| 開発規約/13 | 基本 | 5W1H(5W2H)を明確にする。 |
| 開発規約/174 | Java | 先頭からの String#offsetByCodePoints は検索時間がかかるため避ける |
| 開発規約/173 | 設計、コーディング | 外部リソースの所有者、所有権を明確にする |
| 開発規約/38 | 設計、コーディング | バグパターン |
| 開発規約/115 | 設計、コーディング | エスケープ処理(サニタイズ?)は正しい場所で行う |
| 開発規約/172 | コーディング | タイプ数より、わかりやすさ、変更しやすさを優先する |
| 開発規約/171 | コーディング | 基点は0、件数=終点-始点 の関係にする。 |
| 開発規約/170 | C/C++ | memset で0クリアしてはいけないケース |
| 開発規約/169 | コーディング | for の初期化部でのループカウンタ以外の初期化は禁止 |
| 開発規約/167 | Web | Web で正しくエラーコード(応答コード)を返す |
| 開発規約/166 | 設計 | 入力は寛容に、出力は厳密に |
| 開発規約/165 | | 機能は個別に追加可能にする。抱き合わせにはしない。 |
| 開発規約/164 | | 動いているからOKはダメ |
| 開発規約/163 | 基本 | マニュアルに従って、ツール、API を使う。 |
| 開発規約/145 | HTML | フレーム(frame)は基本的に使わない |
| 開発規約/162 | 命名法 | 命名で予約語との衝突を回避する方法 |
| 開発規約/161 | | かっこよさよりも使いよさ(機能美) |
| 開発規約/160 | | ファイルをアーカイブ(圧縮)する時は、1つのフォルダに入れる。 |
| 開発規約/159 | | 古いバージョンも提供する。 |
| 開発規約/158 | | 現在、開発機として求められる最低性能 |
| 開発規約/157 | | 開発機は1人に2台用意する。または自由貸し出しを行う。 |
| 開発規約/156 | 設計 | 顧客向けエラー表示と開発者向けエラー表示を分ける |
| 開発規約/146 | 設計、コーディング | システムエラーは英語で出す |
| 開発規約/155 | 設計 | 依存性を減らす。他のことを知らなくていいようにする。(いわゆるDI) |
| 開発規約/153 | | キャッシュを使う場合、クリア方法/タイミングを明確にする。 |
| 開発規約/152 | | ビルド環境と実行環境を分ける |
| 開発規約/151 | | 規模を大きくすると失敗するアンチパターン |
| 開発規約/150 | データベース、設計 | データベースに安易にマルチメディアデータを載せない |
| 開発規約/149 | テスト | テストはクリーンな環境で行う |
| 開発規約/148 | 構成管理 | コンパイル不能なソースの結合環境へのコミットは原則禁止 |
| 開発規約/137 | 文書 | あいまいな抽象表現を避け、具体例、参考例を書く。 |
| 開発規約/147 | 基本 | 開発ツール、ライブラリなど、環境のバージョンを揃える |
| 開発規約/144 | 基本 | 安易に「××は禁止」というのは禁止 |
| 開発規約/142 | 運用 | デフォルトを安易に設定しない |
| 開発規約/141 | コーディング | コレクション(集合)の継承は原則禁止 |
| 開発規約/140 | 基本 | 誰が何を知っているのかを正しく把握する |
| 開発規約/138 | | ソース(入力)、中間生成物(ワーク)、完成物(出力)はディレクトリを分ける。 |
| 開発規約/136 | 設計、コーディング | 各種最大サイズについて |
| 開発規約/134 | | Webブラウザでファイルをダウンロードさせる方法について |
| 開発規約/133 | UI | 広告を表示するときの注意点 |
| 開発規約/132 | | 基本的な通信モデルについて |
| 開発規約/131 | 構成管理 | 環境構築のときは可能な限りクリーンな状態、同一の状態から行う |
| 開発規約/11 | 基本 | 開発に必要と思われる文書の一覧 |
| 開発規約/130 | UI | 後方のアプリケーションはフォーカスを奪ってはならない |
| 開発規約/128 | 文書 | 文書は適当に分割する。1つの文書に詰め込まない。 |
| 開発規約/127 | 基本 | 方法を知っていても、他の方法がないかもう一度調べてみる。 |
| 開発規約/125 | 設計 | 用語辞書を作る |
| 開発規約/124 | コーディング | 被除数が負の場合の剰余の取り扱いについて |
| 開発規約/122 | | 考えられるソフトウェア販売ビジネスモデルについて |
| 開発規約/121 | | バックアップについて |
| 開発規約/119 | | 考慮が必要なWebブラウザについて |
| 開発規約/40 | 設計、命名法 | 基本用語辞書 |
| 開発規約/117 | 設計 | 単位系について |
| 開発規約/116 | コーディング | ウィザードに頼り過ぎない。ウィザードがやっていることを理解する。 |
| 開発規約/114 | 設計 | スケール(規模)によった最適設計をする |
| 開発規約/104 | | サーバーの物理移転の時の注意点 |
| 開発規約/112 | 設計 | 認証、本人証明の方法について |
| 開発規約/111 | 設計 | ミドルウェアのカスタマイズは極力避ける |
| 開発規約/110 | 設計 | 複数の概念をごちゃ混ぜに扱わない |
| 開発規約/109 | | インストールで使ったファイルは全て残す |
| 開発規約/107 | 設定 | /etc/host と DNS の使い分け |
| 開発規約/106 | | 連番、シリアル番号を安易に使わない |
| 開発規約/101 | 設計、コーディング | ポインタと番号とどちらを使った方がいいか |
| 開発規約/105 | | 古いバージョンとの同居を考慮すること |
| 開発規約/103 | Web | 不特定多数が見るページにユーザーのメールアドレスを直接載せない |
| 開発規約/102 | 文書 | A判を使う。B判は避ける。 |
| 開発規約/99 | 設計 | 現状においてシステム化困難なもの |
| 開発規約/98 | 設計,アーキテクチャ | 現実的に選択可能なWebクライアントサーバー技術 |
| 開発規約/77 | 設計,アーキテクチャ | 現実的に選定可能なOS |
| 開発規約/97 | 設計 | オブジェクト指向アンチパターン |
| 開発規約/79 | Ruby,PHP,Perl | 文字列は通常ダブルクォーテーションで括る。 |
| 開発規約/94 | テスト | 負荷テスト時の注意点 |
| 開発規約/88 | コーディング、HTML | HTML出力で必要なエスケープ |
| 開発規約/64 | 設計 | ユーザーインターフェイス(UI)を安易に変更しない |
| 開発規約/65 | 設計、コーディング | メソッドからのエラーの返し方について |
| 開発規約/93 | Java | 定数(定値)は static final にする。 |
| 開発規約/92 | 設計、HTML | HTML での入力画面設計 |
| 開発規約/50 | サーバー設定 | パーティションを適度に切る。 |
| 開発規約/91 | 設計 | 入力の書き換えは極力避ける。オリジナルデータを残す。 |
| 開発規約/90 | 設計 | 大量データの時に安易に集合オブジェクトを使わない |
| 開発規約/89 | Java | 金銭計算では BigDecimal を使う |
| 開発規約/75 | 設計,アーキテクチャ | 現実的に選定可能なプログラミング言語 |
| 開発規約/39 | 設計 | 設計チェックシート |
| 開発規約/87 | 設計 | 長期間使えるものを作る |
| 開発規約/86 | 設計、サーバー設定 | 時計を合わせる |
| 開発規約/85 | 行動規範 | Win-Win の関係を目指す。 |
| 開発規約/84 | 設計、コーディング | ユーティリティメソッドの追加は慎重に行う |
| 開発規約/29 | 基本 | 最新の情報を得る。古い情報に頼らない。 |
| 開発規約/83 | ネットワーク | ホスト名、ドメイン名、FQDN の区別を明確にすること。 |
| 開発規約/81 | 設計,コーディング | 同一と同値を混同しない。 |
| 開発規約/80 | Java | クラスメソッドを使うためにインスタンスを生成してはならない |
| 開発規約/55 | データベース | EXPLAINでSQLのアクセス方法を確認する。 |
| 開発規約/47 | 設計 | クライアントからのデータを信用してはならない。入力は必ずサーバーでチェックする |
| 開発規約/73 | データベース | データベースの更新方法について |
| 開発規約/78 | 保守 | バージョンアップ、セキュリティパッチ適用は慎重に行う。 |
| 開発規約/76 | 設計,アーキテクチャ | 現実的に選定可能なデータベース |
| 開発規約/60 | 基本 | 行き当たりばったり、トライアンドエラーを避ける |
| 開発規約/63 | 設計 | 独自ユーザーインターフェイス(UI)は使わない |
| 開発規約/69 | 設計 | 標準のものを使う。特別なものは極力避ける。 |
| 開発規約/71 | 設計,保守 | 常時ログを取る |
| 開発規約/44 | 設計 | 設計アンチパターン |
| 開発規約/74 | データベース | 検索は1000件までを限界にする。 |
| 開発規約/72 | 設計 | オリジナルのデータを残す。 |
| 開発規約/68 | 基本 | 不要になったものは捨てる |
| 開発規約/70 | | 客先に渡すものは、未来永劫使われるつもりで作る。 |
| 開発規約/67 | 運用 | MX レコードを消す前に、そのドメイン名で送信するメールがないことを確認する。 |
| 開発規約/62 | | いざとなったらプロトコルを直接叩いて確認する。 |
| 開発規約/61 | | 作ったメディアにはすぐラベルを付ける |
| 開発規約/59 | 設定 | 「メールサーバーにメールを残す」設定をさせないこと |
| 開発規約/58 | | トランザクション内に長期間待ち処理を入れてはならない |
| 開発規約/57 | 命名法 | サーバーの名前は、マシン名と機能名の両方を付ける |
| 開発規約/56 | 設計 | プログラミング言語を統一する。無闇に異なる言語を使わない。 |
| 開発規約/54 | | ドメイン名はできる限りFQDNで指定する。 |
| 開発規約/53 | | ファイル配置 |
| 開発規約/51 | 基本 | 対数(指数)的に見積もる |
| 開発規約/5 | 基本,命名法 | わかりやすい名前をつける。 |
| 開発規約/49 | プロジェクト管理 | 1日未満のタスクは余り細かく見積もらない |
| 開発規約/46 | コーディング | 本番機でコーディングを行わない |
| 開発規約/45 | 設計 | メールシステムでの考慮点 |
| 開発規約/1 | 基本 | 二重化させない。共通化する。 |
| 開発規約/43 | 基本 | 本当の原因を突き止めて対策する。その場限りの対処療法を避ける。 |
| 開発規約/42 | テスト | テストのやり方 |
| 開発規約/41 | テスト | テストケースの作り方 |
| 開発規約/37 | 基本 | 分割統治する。大きな難しい問題は、小さな簡単な問題に分解して取りかかる。 |
| 開発規約/36 | データベース | 全フィールドの読み出しを安易に使わない。 |
| 開発規約/35 | 命名法 | カテゴリ名は右(前方)につける |
| 開発規約/34 | 命名法 | Yes/No を返すメソッド(関数)には、Yes/No がはっきりする名前をつける。 |
| 開発規約/32 | 基本 | チェックリストを使う。 |
| 開発規約/31 | 基本 | 必要なものは文書化する。 |
| 開発規約/30 | 基本 | 知ったかぶりはしない。知らないことは知らないと言う。 |
| 開発規約/28 | プロジェクト管理 | 作業を単純分割しない。 |
| 開発規約/27 | 人事 | 適材適所となるようにする。 |
| 開発規約/26 | 文書 | 一部を無効化するために、一部を隠す方式は使わない。 |
| 開発規約/25 | 基本 | 1つ間違いを見つけたら、類似の間違いがないか確認する。 |
| 開発規約/24 | コーディング | 正常の場合、正常の場合、正常の場合…というネストを避ける |
| 開発規約/23 | 設計 | 1回で済むことは1回で済ませる。 |
| 開発規約/22 | 基本 | サンプル、プロトタイプを安易に真似しない。 |
| 開発規約/21 | 基本 | サンプル、プロトタイプは高品質のものを作る。手を抜かない。 |
| 開発規約/20 | 基本 | 開発規約の目的 |
| 開発規約/19 | 基本 | 予備的に余計なものを付け加えない。 |
| 開発規約/18 | 基本 | 間違いを見つけたら、その場で修正する。後回しにしない。 |
| 開発規約/15 | 仕様書 | プログラムと同じ詳細レベルのプログラム設計書を書いてはならない。 |
| 開発規約/16 | 基本 | 原因究明するときは、要因を1つづつ試す。 |
| 開発規約/14 | 基本 | 実装が含まれるような名前を避ける |
| 開発規約/10 | 基本 | 1次情報を確認する。2次情報に振り回されない。 |
| 開発規約/9 | 基本 | 簡潔にする |
| 開発規約/7 | Java | new String("文字列") としない。"文字列"のみとする。 |
| 開発規約/8 | コーディング | 例外処理の方法について |
| 開発規約/2 | コーディング | マジックナンバーを使わない。定数には名前をつける。 |
| 開発規約/6 | コーディング | 関数、メソッドの長さは高々100行までにする。 |
| 開発規約/4 | コーディング | ハードコーディングしない。定数などは外に置く。アルゴリズムは汎用にする。 |
| 開発規約/3 | 基本 | 車輪の再発明をしない。既存のものを利用する。 |