既存のコードベースのプロジェクトのコーディング標準/スタイルガイドの進化にどのように対処しますか？あなたのチームの誰かがプログラミング言語でオブジェクトのインスタンス化のより良い方法を発見したとしましょう。古い方法が悪いことやバグがあるということではなく、新しい方法のほうが冗長でなく、はるかにエレガントだと感じるだけです。そして、すべてのチームメンバーが本当に気に入っています。既存のコードをすべて変更しますか？
コードベースが約500.000行以上のコードであるとします。それでも既存のコードをすべて変更しますか？それとも、新しいコードのみを新しい標準に準拠させますか？基本的に一貫性を失いますか？
プロジェクトのコーディング標準の進化にどのように対処しますか？
回答:
チームの生産性を高めるためのコーディング標準が存在します。理論的には、コードを理解、変更、テストしやすくします。実際には、危険な量のメタワークを作成できます。チームは、最も正確でエレガントなソリューションを追求して、既存のコードを何度も書き直します。残念なことに、メタワークの問題は、誰もが熱心で、正しいことを行うことに夢中になっているチームではさらに悪いように思われます。
プロジェクトからプロジェクトへと移行するコンサルタントとして、厳格なコーディング標準を備えた優れた規律は、結果に関心のある優秀な開発者よりもプロジェクトの成功にはるかに貢献しないことがわかりました。一貫性のないコーディングスタイルは、驚くべき開発者にとっては厄介なものです。一貫性の有無にかかわらず生産的です。確かに、一貫性のないコードに遭遇した場合は、現在の標準とそれに固執する。ただし、プロジェクトのすべてのコード行を現在の標準に更新することを主張しません。彼らはベストプラクティスが行き来するのを見てきたので、彼らは主張しません。今日何かをする正しい方法は、明日何かをする正しい方法と同じではありません。もしそうなら、コーディング標準は進化しません。したがって、何かを行う正しい方法が時間とともに変化する場合、「正しい」という私たちの定義が壊れている可能性があります。
それは、標準が重要ではないということではありません。標準の目標は生産性であることに留意してください。新しい標準への書き直しが長期的に見返りを保証できない場合は、時間を無駄にしないでください。新しいコードまたはリファクタリングされたコードで新しい標準を正当化する方がはるかに簡単です。エレガンスはクールですが、結果と同じではありません。
まず、コーディングガイドライン（の必須部分）にこのような「ベストプラクティス」を含めません。それらは、たとえば付録で、あなたが何かをする方法の例として言及されるかもしれませんが、それがそのようにされるべきではありません。
とはいえ、コーディング標準の変更を検討する場合は2つあります。
これは、作成する製品のタイプに本当に依存する必要があります。
個人的には、古いコードをそのまま残し、新しいことは何でも新しい標準に従うことを選択します。具体的には、old.cで二重標準を使用しません。ただし、new.cを作成する場合は、より洗練された新しい構文を使用できます:)