最近、私の同僚は、コードのレビューでスタイルについての執lentなコメントを聞いた。 当然化粧品と呼べるものにますます注意を払っています。 はい、悪いコードスタイルがあります、より良いものがありますが、それらはすべて単なる慣習です。 それらの一部がコードの全体的な品質を実際に改善することは否定できませんが、スペースやタブについてどれほど議論しても、それらは主観的な好みのままであり、しばしば好みの問題です。
ただし、気になるのはコードの品質ではなく、コードの品質を決定するのは眼精疲労やランダム読み取りエラーほどではありません。 私たちは、急いで誤解しない限り回避できるはずの間違いとしばしば闘います。
開発者はコードを書くだけでなく、ほとんどの場合、その小さな断片を追加、削除、編集します。実際、巨大なコードに小さな変更を加えます。 ゼロから作成された独立したコードフラグメントはめったに出会うことはありません-もちろん、新しいプロジェクトを開始しない限り。 私たちのプロジェクトのほとんどは、多くの世代の開発者の遺産です。 新しい機能を追加したり、古い機能を変更したりする場合は、コードを読んで、どのチームが何をどのように実行してアイデアを実装するのかを判断する必要があります。 完全に独立したモジュールまたはクラスで作業している場合でも、最初の行を作成したら、それらに何度も戻って新しいコードを織り込む必要があります。
奇妙なことに、経験を積むほど、コードを変更する前にコードを読むことに専念する時間が増え、これは理にかなっているように思えます。 新しいコードを書くことは、既存のコードを理解して使用するよりもはるかに簡単ですが、最も簡単な方法が最終的に常に最良とは限りません。 もちろん、この大文字と小文字を区別しない文字列比較関数を再度必要に応じて30回記述する方が高速になります-または、そのように思えますか？ 実際、エラーなどが新しい関数に忍び寄る可能性があり、手遅れになるまで気付かないでしょう。 努力をして、使用できる既存の実装を見つけるのはそれほど難しくありません-古いコードでも可能ですが、そのためにはそれを読むことができる必要があります。 （私は自転車の発明を大罪とは考えていません。これが最良の選択である場合もありますが、それはまったく異なる話です。）コードを読むことのもう1つの大きな副作用は、エラーを見つけて、すぐに修正しない場合は報告することです
新しいコードを書くか、既存のコードまたはライブラリコードを使用するかの合理的な選択は、両方のオプションのオーバーヘッドを考慮した場合にのみ可能です。最初のケースで潜在的なエラーを検索するか、2番目のケースで調査して埋め込むためです。 残念ながら、これを実現するには経験が必要です（ Dunning-Krueger効果 ）。
レガシーコードのサポートまたは独自のコードの作成の問題は、まったく異なる議論です。 継承されたコードの改善は、その破壊よりもほぼ常に優れていることに注意してください。リスクが少なく、常に機能するフラグメントがあり、基礎として使用できるコードがあります。 この記事のアイデアは、コードの書き換えを避けるために、開発者は既存のコードを読み、それをうまく読むことができる必要があるということです。 そのためには、コードを読みやすくする必要があります。
詳細に移りましょう。 これは、コードの可読性を向上させるために重要だと思うものです。
1.一貫性。
ほとんどすべてのスタイルのコードを問題なく読むことができます。 適応することを学ばなければなりませんでした。 コードを読む必要があると思う場合、そのスタイルが私のお気に入りと異なる可能性があることに同意する必要があります。 QWERTYからDvorakに切り替えた5歳の子供が書いたように、たった1つのこと、つまりコードに適応することは不可能です。 自分でスタイルを選択するか、自分にスタイルを課すかに関わらず、プロジェクト全体でそれを守ります。
2.一貫性。
リストの最初の2つの場所に値するほど重要です。 人々は括弧内の次の行と括弧内のこの行を試し、それを忘れてしまい、彼らの実験はリポジトリで終わり、残りのチームを悩ます。 真剣に、スタイルを試すことは良いことですが、それらをコミットする必要はありません。
3.スペースを追加します。
コードはテキストに似ています：誰もが書式設定や段落なしでテキストの「シート」を読むのが嫌いです。したがって、これはコードにも当てはまります。 ブロックとスコープは空白行で区切ります。 閉じブラケットは、彼らにとって素晴らしい場所です。 コメントを追加しますか？ さて、コードが2列でフォーマットされている場合、新聞スタイルは必要ありません。左側のコードと右側のコメントです。 これは便利ですが、通常はコメントの場合、ブロックまたはコマンドの前ではなく、それらの隣ではありません。 コメントの前に空の行を追加することをお勧めします。 十分なディスク容量があることを忘れないでください。長い関数、巨大なクラス、長いファイルを分割します。 関数を適切なサイズにします。 循環的複雑度などのメトリックを使用して、コードが複雑になりすぎて読み取りや理解が困難になる時期を判断します。 リファクタリングを行います。
4.バナーのコメントを投稿してください！
関数内に5行のコメント行を含むバナーを追加したいという願望は、この関数の前に新しいバナーを配置する必要があることを示しています。 私はそれをまったく使わずにやりたいと思いますが、半ダースのバナーを持つ1000行ごとに1つの機能よりも優れています。 実際、新しい論理ブロックの開始をマークする場合は、それを関数にすることをお勧めします。 同じことが、長い関数、クラス、およびファイルにも当てはまります。
5.マジックナンバーを使用しないでください。
定数は、コードの基になっている数字に名前を付けるための優れたツールです。 デフォルト値、コンテナサイズ、タイムアウト、およびユーザーへのメッセージは、定数ができることのほんの一例です。 数字を定数で置き換える必要はありません-それらは発明されていません。
6.賢明に名前を選択してください。
変数と関数の命名、および類似の名前を選択することの危険性に関する多くの文献があります。 ただし、一部の無責任な要素は、あいまいな名前と、論理境界を超えた変数の再利用を依然として主張しています。 名前は、意味のある明確なだけでなく、すべての機能、クラス、およびモジュールで、理想的にはプロジェクト全体で一貫している必要があります。 まあ、少なくとも試してみてください！
7.チェーンで記述しないでください。
多くの人は、カンマで区切られた同じタイプのすべての変数を同じ行で宣言する練習をしています。 これは、それを必要とし、コマンドの後に変数を宣言することを許可しなかった言語に由来します。 言語でこれが許可されている場合は、変数が使用される場所にできるだけ近い場所で変数を宣言し、それらを再利用しないでください（まったく同じ目的でない限り）。
チェーン内の同様のコードスキームは、他の関数を呼び出した結果が、中間変数に保存せずに1つの関数に引数として渡されたときに発生します。 一部の人々は、それがよりコンパクトであると思い、3〜4個のネストされた関数を追加すると考えています。 多くの場合、特にエラーのスキームで関数のすべての副作用をチェックする必要がある場合は、まったく逆になります。
8.行とファイルのサイズを制限します。
水平スクロールはひどいです。テキストを各行で左右に反転させて読むことを期待することはできません。 さまざまな人がさまざまなサイズの画面を持っていますが、多くは視力が悪いために大きなフォントを使用しています。 同時に、多くの開発者は画面の最大幅を使用し、場合によっては行の長さをまったく制限しないこともあります。 これは非常に不便です 多くの開発環境では、行ごとのコードラッピングが失敗すると、そのフォーマットが破壊されます。
歴史的な標準から始めることができます-1行あたり80文字：狭すぎず、ほとんどのモニターと設定でサポートされています。 チーム全体が100文字または120文字の文字列を処理できる場合は、それらを標準として使用できます。 しかし、ここでは無理をしないようにすることが重要です。長すぎる行は、それ自体で読みにくくなります。 新聞や雑誌を考えてみてください-コラムの幅と読みやすさ。 目だけでなく頭も動かさなければならない線を読むと、身体的なストレスが増え、作業が遅くなります。
9.スコープを明示的にします。
多くの言語では、スコープは暗黙的です。 Cのような言語での条件分岐またはループの後の最初のコマンドは、明らかにその範囲に入りますが、次のコマンドではありません。 書式設定が失敗した場合、ブロックの終わりを追跡して、まだどのコマンドがそれに属しているか、どのコマンドがもう存在しないかを見つけることは非常に困難です。 明示的にブロックを選択し、括弧と空行を閉じ括弧の後に追加するフォーマットは、ループ本体が1つのコマンドである場合でも、コードの可読性を大幅に向上させます。
10.コメント。
コードは、紛らわしくて霧がかかっていても、コンピューターによく理解されています。 しかし、人々は反対に、コードが何をするのかだけでなく、コードの目的とそのように書かれた理由も理解する必要があります。 特定の構造、操作、および値を理解しないと、開発者はコードを有意義に維持できません。 コメントは、明らかでないコードのニュアンスを伝えるための優れたツールです。 ビジネス要件、前提条件、要件、パッチ、および回避策を説明します。 コメントを通じて開発パートナーに相談してください。 ただし、例外のないルールはありません。コメントを乱用しないでください。 例外をスローする前に「今すぐエラーが発生します」と書かないでください。throwコマンドはそれ自体を語っています。 この場合、何も修正できない理由を説明します。
結論として、一部のコードは読み取り不可にする必要があることに注意してください。 はい、あなたの目はあなたを欺かない。 ハッキング、悪い習慣、または回避策に基づいて構築されたコードは、よく読まれないはずです。 私の最も良い例は型キャストです。 多くの場合、オブジェクトのインスタンスを特定のタイプに減らす必要があります。これは標準的な方法ですが、推奨される方法ではありません。 少し読みにくい形式で変換を書くことは、読者を停止させ、これが間違いではないことを確認させる良い方法です。 これはやや斜体のテキストに似ており、読みにくく、際立っています。 同様に、回避策とハッキングが目立つはずです。 TODOおよびFIXMEマーカーは良い出発点です。 実際、コードのどこかにバナーコメントが必要な場合は、ここにあります-既知の問題をコードから突き出させます。 （主なことは、それらを修正することを忘れないことです！-約。）
これらの記事のほとんどと同様に、これは特定の要件ではなく、主にコードの可読性の原則に関するものです。 それらは厳密に定義されておらず、決して完全ではありません。 すべての言語、エコシステム、フレームワーク、ライブラリには独自のニュアンスがあり、一部の言語で明らかなことは曖昧で、他の言語では望ましくない場合があります。 引き出される重要な結論は、読者のためにコードを書き、あいまいなスタイルを避け、コンテキストを監視し、コメントを書くタイミングとリファクタリングを行うタイミングを評価する必要があるということです。