ルール
削除 コメントアウトされた コード ブロック
コメントアウトされた コード ノイズを生成する ノイズを 陳腐化し 時代遅れになり、
そして 属する に バージョン 管理 履歴に ではない コードベース コードベースではない。はじめに
開発者が古いロジックを後で必要とするか確信が持てない場合、コメントアウトされたコードが蓄積される。誰かが関数を削除せずに「万一に備えて」コメントアウトすると、それが永久に残存する。このコードがまだ動作するか、なぜ無効化されたか、削除しても安全か――誰も把握していない。コードベースは過去の実装の亡霊で埋め尽くされ、本番環境で実際に動作しているものを理解する妨げとなる。
なぜそれが重要なのか
コードの保守性：コメントアウトされたコードは、読者に「実際に動作している部分」と「休止状態の部分」を頭の中で選別することを強いる。コードレビュー時には、これらのブロックが一時的な実験なのか、重要なロールバックオプションなのか、あるいは何年も前に忘れ去られた残骸なのか判断できない。このノイズにより、実際のロジックの理解、関連するコードセクションの発見、そして意味のある変更レビューが困難になる。
セキュリティ上の影響：コメントアウトされた認証チェック、検証ロジック、またはセキュリティ機能は、これらの保護機能が存在していたが意図的に無効化されていたことを示しています。コメントアウトされたコードに認証情報、APIキー、内部URLが含まれている場合、その機密データを平文で公開していることになります。攻撃者がコードベースを調査すれば、あなたが検討した上で削除したセキュリティ対策の内容を正確に把握できます。
バージョン管理の混乱：Gitの差分表示は、実際には変更されていないコメントアウトされたブロックで乱雑になる。ロジックがいつ変更されたか、あるいは機能が特定の動作をする理由を追跡する必要がある場合、コメントアウトされた代替案が実際の履歴を覆い隠してしまう。コードベースを検索すると、実行されないデッドコード内のマッチが返され、実行されないパスを調査する時間が無駄になる。
コード例
非準拠：
async function createUser(userData) {
// const hashedPassword = await bcrypt.hash(userData.password, 10);
const user = await db.users.create({
email: userData.email,
password: userData.password,
// password: hashedPassword,
role: userData.role || 'user'
});
// await sendWelcomeEmail(user.email);
// await notifyAdmins(user);
// Old validation approach
// if (!isValidEmail(user.email)) {
// throw new Error('Invalid email');
// }
return user;
}
問題点：コメントアウトされたパスワードハッシュ処理から、パスワードが平文で保存されていることが判明しており、重大なセキュリティ上の脆弱性です。ウェルカムメールと管理者通知の有効化要件が不明確であり、古い検証処理からメール検証が欠落している可能性があります。
✅ 準拠：
async function createUser(userData) {
if (!isValidEmail(userData.email)) {
throw new Error('Invalid email');
}
const hashedPassword = await bcrypt.hash(userData.password, 10);
const user = await db.users.create({
email: userData.email,
password: hashedPassword,
role: userData.role || 'user'
});
await sendWelcomeEmail(user.email);
await notifyAdmins(user);
return user;
}
重要性：この関数は明確かつ完全であり、本番環境で正確に実行される内容を示しています。メール検証が最初に実行され、パスワードは適切にハッシュ化され、有効化されている機能に曖昧さなくすべての通知が送信されます。
結論
コードをコメントアウトする代わりに削除してください。バージョン管理システムは過去に記述されたすべての行を保存しており、以下を通じてアクセス可能です。 git log そして git blame 必要な時に。コメント付きのコードをリポジトリに残すのは、実際のロジックを覆い隠すノイズを生み、コードベースの理解を難しくするだけです。
.avif)
