コードを標準化するときの距離
私の小さなチームと私は、すべてPerlで、フル機能のAPIを備えた適切なサイズのWebアプリケーション（約5万行）を作成しました。私たちPerlハッカーが知っているように..だらしないのは簡単です。多くのレガシーコードを移植する必要がありました。したがって、Perlクジラの根性コードが続きました。
簡単に言うと、時間の制約がかなり厳しく、現在は延期されているため、戻ってコードを標準化する時間があります。
請負業者がiOSアプリを開発していたときに、コードがどれほど非標準であるかがすぐにわかりました。このアプリでは、アカウント番号が10の場所、12の場所にデータが追加されています。
日付形式とデータ形式の修正を行っていると、レガシーコードに由来する、非常にわかりにくい変数とハッシュキーの名前が大量にあることに気づきました。
基本的に、私の質問は-上記のシナリオまたはあなた自身の経験を考えると、クリーンアップして標準化するときにどこまで行きますか？ハッシュキー名をより長いキャメルケースの名前、変数名、結果でのデータの処理方法などに置き換えてみる価値はありますか？.
動作中のコードを壊すことでさらに多くの苦痛が生じる可能性があることを私は知っています、そしてそれは価値がないかもしれません..しかし、どのようにあなたはどこまで行くのかを知っていますか？今すぐそれを乗り越えて、後でそれが報われるのか、それともちょっとした「コードの借金」で生きるのか？
TL; DR：自動リンティングとコミットフックコードリフォーマッターを使用します。
私がPerlをやっていたとき、テストスイートにlintチェッカーを配置し、コードを自動的に再フォーマットするコミットフックを配置することにしました。これは、コードの一貫性の欠如やリンティングの問題によって今後さらに技術的負債が発生しないようにするためです。
コードベース全体を一度に新しい標準に引き上げるのに時間コストをかけたくなかったので、リンターが投げた正確なエラー（行番号を含む）に基づく明示的な例外を除いて、それらを適用除外しました。例外は意図的に壊れやすいため、次に誰かがファイルに触れたときに、リンターによって設定された基準に合わせる必要がありました。
時間の経過とともに、チームの標準に基づいたカスタマイズでリンターとコードリフォーマッターを拡張しました。これにより、自動テストと継続的インテグレーションを使用して、リンティングバグを排除することができました。リフォーマッターが変更されたときは、それをまとめて実行し、変更をコミットします。可能な限り多くのことについて、変更を強制する（コードを再フォーマットする）か、問題をキャッチする（リンティング）ための自動ドライバーを作成しました。私たちは自分たちのためにかなり完全な基準まで運転を終えました。確かに、標準化や一貫性に関する関連する問題が発生した後、実際に問題が発生することはありませんでした。おそらく、使用するイディオムと使用しないイディオムに関するものもありますが、それらでさえ、lint拡張機能に組み込まれています。