🎅🏿 📤 🏞️ コードの読みやすさ 💉 🥨 👂🏿

コードを使用してインターフェイスを作成します。しかし、コード自体はインターフェースです。

コードの読みやすさが非常に重要であるという事実にもかかわらず、この概念は不十分に定義されており、多くの場合、単なるルールのセットの形式です：意味のある変数名を使用し、大きな関数を小さなものに分割し、標準設計パターンを使用します。

同時に、確かに、誰もがこれらの規則に準拠するコードを扱わなければなりませんでしたが、何らかの理由で何らかの混乱を表しています。

新しいルールを追加することで、この問題の解決を試みることができます。変数名が非常に長くなる場合、メインロジックをリファクタリングする必要があります。 1つのクラスに多くの補助メソッドが蓄積されている場合、おそらく2つに分割する必要があります。設計パターンを間違ったコンテキストに適用することはできません。

そのような指示は主観的な決定の迷路に変わります。その中をナビゲートするには、適切な選択を行える開発者が必要です。つまり、読み取り可能なコードをすでに作成できる必要があります。

したがって、一連の指示はオプションではありません。したがって、コードの読みやすさのより広い観点を定式化する必要があります。

可読性とは何ですか？

実際には、読みやすさは通常、コードが読みやすいことを意味します。しかし、そのような定義にまで踏み込むことはできません。第一に主観的であり、第二に通常のテキストを読むことに拘束されます。

読み取り不可能なコードは、コードのふりをした小説として認識されます：起こっていることの本質を明らかにする多くのコメント、順番に読む必要があるテキストのシート、スマートな言葉遣い、唯一の意味は「スマート」であること、言葉を再利用する恐怖開発者はコードを読みやすくしようとしていますが、間違ったタイプのリーダーをターゲットにしています。

テキストの読みやすさとコードの読みやすさは同じではありません。

Alconostに翻訳

コードを使用してインターフェイスを作成します。しかし、コード自体はインターフェースです。

コードがきれいに見える場合、それは読み取り可能という意味ですか？美学は読みやすさの好ましい副作用ですが、基準としてはあまり有用ではありません。おそらく極端な場合、プロジェクトのコードの美学は従業員を維持するのに役立ちますが、同じ成功を収めれば、優れたソーシャルパッケージを提供できます。さらに、誰もが「美しいコード」の意味について独自の考えを持っています。そして、時間の経過とともに、読みやすさのこの定義は、表、スペース、括弧、「ラクダ表記」などに関する論争の渦に変わります。間違ったインデントを見たときに誰もが意識を失うことはありません。

コードで生成されるエラーが少ない場合、読みやすくなると考えられますか？エラーが少ないほど良いですが、どのようなメカニズムがありますか？コードを読んだときに経験する漠然とした快感をどのように帰属させることができますか？また、コードの読み取り中に眉が眉をひそめていても、エラーは追加されません。

コードが編集しやすい場合、読みやすいですか？しかし、これはおそらく、正しい思考の方向です。要件の変更、機能の追加、エラーの発生-そして、ある時点で誰かがコードを編集する必要があります。そして、新しい問題を引き起こさないために、開発者は自分が何を編集しているか、変更がコードの動作をどのように変更するかを正確に理解する必要があります。そこで、新しいヒューリスティックルールを見つけました。読み取り可能なコードは簡単に編集できるはずです。

どのコードが編集しやすいですか？

すぐに、「変数の名前に意味のある名前を付けるとコードの編集が簡単になります」とあいまいにしたいのですが、「読みやすさ」を「編集しやすい」に変更します。私たちはより深い理解を必要とし、別の装いで同じルールのセットを必要としません。

まず、コードについて話していることを忘れることから始めましょう。プログラミングは数十年前のものであり、人類の歴史の規模のほんの一部に過ぎません。この「ポイント」に限定して、深く掘り下げることはできません。

したがって、デジタルのステップだけでなく、ほぼすべてのステップで遭遇するインターフェースを設計するプリズムを通して読みやすさを見てみましょう。おもちゃには、乗ったり、きしむことができる機能があります。ドアには、ドアの開閉、ロックを可能にするインターフェースがあります。ブック内のデータはページ単位で収集され、スクロールよりも高速なランダムアクセスを提供します。設計を勉強すると、これらのインターフェースについてさらに学ぶことができます-可能であれば設計チームに問い合わせてください。一般的な場合、何が良いのかが常にわからないとしても、私たちは皆、良いインターフェースを好みます。

コードを使用してインターフェイスを作成します。しかし、コードとIDEを組み合わせたものはインターフェースです。非常に小さなユーザーグループ-同僚のために設計されたインターフェイス。さらに、それらを「ユーザー」と呼びます-ユーザーインターフェイスのデザインスペースに残るためです。

これを念頭に置いて、次のユーザーパスの例を検討してください。

ユーザーが新しい関数を追加したい。これには、適切な場所を見つけ、新しいエラーを生成せずに機能を追加する必要があります。
ユーザーがエラーを修正したい。問題の原因を見つけ、コードを編集して、エラーが消えて新しいエラーが表示されないようにする必要があります。
ユーザーは、境界線の場合にコードが特定の方法で動作することを確認したいと考えています。彼は特定のコードを見つけて、ロジックをトレースし、何が起こるかをシミュレートする必要があります。

など：ほとんどのパスは同様のパターンに従います。物事を複雑にしないために、特定の例を検討しますが、それは一般原則を検索することであり、規則のリストを作成することではないことを忘れないでください。

ユーザーがコードの目的のセクションをすぐに開くことができないと自信を持って想定できます。これはあなた自身の趣味のプロジェクトにも当てはまります。関数があなたによって書かれたとしても、それがどこにあるかを忘れることは非常に簡単です。したがって、適切なコードを簡単に見つけられるようなコードにする必要があります。

便利な検索を実装するには、検索エンジンの最適化が必要になります-ここでは、変数の意味のある名前が助けになります。ユーザーが関数を見つけられない場合、既知のポイントから呼び出しスタックに沿って移動すると、キーワードによる検索を開始できます。ただし、名前に多くのキーワードを含めることはできません。コードで検索する場合、さらに作業を続けることができる唯一のエントリポイントが求められます。したがって、ユーザーは特定の場所に到達するのを手伝う必要があり、キーワードでそれをやり過ぎると、無駄な検索結果が多くなりすぎます。

ユーザーが特定のレベルのロジックですべてが正しいことをすぐに確認できる場合、前の抽象レイヤーを忘れて、次の抽象レイヤーを解放できます。

オートコンプリートを使用して検索できます。どの関数を呼び出すか、またはどの列挙を使用するかの一般的なアイデアがある場合は、目的の名前の入力を開始し、オートコンプリートリストから適切なオプションを選択できます。関数が特定のケースのみを対象としている場合、または使用機能のために実装を注意深く読む必要がある場合は、より本格的な名前を付けることでこれを示すことができます：自動補完のリストをスクロールすることで、ユーザーはむしろ複雑に見えるものを避けます-もちろん、何をしますか。

したがって、短い通常名は、「カジュアル」ユーザーに適したデフォルトオプションとして認識される可能性が高くなります。このような名前の関数には驚きはありません。インターフェイスの[表示]ボタンでユーザーデータを変更しないのと同じ理由で、単純なゲッターのように見える関数にセッターを挿入することはできません。

クライアント側のインターフェイスでは、一時停止などの使い慣れた機能はほとんどテキストなしで機能します。 機能がより複雑になると、名前が長くなり、ユーザーの反応が遅くなり、考えがつきます。 スクリーンショット-Pandora

ユーザーは適切な情報をすばやく見つけたいと考えています。ほとんどの場合、コンパイルにはかなりの時間がかかり、実行中のアプリケーションでは、多くの異なる境界ケースを手動でチェックする必要があります。可能であれば、ユーザーは、ブレークポイントを設定してコードを実行するよりも、コードを読んでその動作を理解することを好みます。

コードを実行せずに実行するには、2つの条件が満たされている必要があります。

ユーザーは、コードが何をしようとしているかを理解しています。
ユーザーは、コードが主張するとおりに動作することを確信しています。

抽象化は、最初の条件を満たすために役立ちます。ユーザーは、目的の詳細レベルまで抽象化のレイヤーに飛び込むことができる必要があります。階層的なユーザーインターフェースを想像してください。最初のレベルでは、ナビゲーションは広範なセクションに渡って実行され、さらに具体化されます-より詳細に検討する必要のあるロジックのレベルまで。

ファイルまたはメソッドの順次読み取りは、線形時間で実行されます。しかし、ユーザーが呼び出しスタックを上下に移動できる場合-これはツリー内の検索であり、階層のバランスが取れている場合、このアクションは対数時間で実行されます。インターフェースにはリストの余地は確かにありますが、コンテキストによっては2つ以上のメソッド呼び出しが必要かどうかを慎重に検討する必要があります。

短いメニューでは、階層ナビゲーションがはるかに高速です。 右側の「長い」メニュー-11行のみ。 メソッドコードでこの数値にどのくらいの頻度で適合しますか？ スクリーンショット-Pandora

ユーザーが異なれば、2番目の条件に対する戦略も異なります。低リスクの状況では、コメントまたはメソッド名で十分な証拠となります。よりリスクが高く、複雑な領域では、コードが無関係なコメントでオーバーロードされている場合、後者は無視される可能性があります。メソッドや変数の名前さえ疑わしい場合があります。そのような場合、ユーザーはより多くのコードを読み、より広範な論理モデルを念頭に置く必要があります。また、把握しやすい小さな領域にコンテキストを制限するのにも役立ちます。ユーザーが特定のレベルのロジックですべてが正しいことをすぐに確認できる場合、前の抽象レイヤーを忘れて、次の抽象レイヤーを解放できます。

この操作モードでは、個々のトークンがより重要になり始めます。たとえば、ブールフラグ

element.visible = true/false

残りのコードから分離して理解するのは簡単ですが、これには2つの異なるトークンを頭の中に組み合わせる必要があります。使用する場合

 element.visibility = .visible/.hidden

フラグの値はすぐに理解できます：この場合、変数名を読んで可視性に関連していることを確認する必要はありません。¹クライアント指向のインターフェースを設計する際に同様のアプローチを見ました。過去数十年にわたって、[OK]ボタンと[キャンセル]ボタンはよりわかりやすいインターフェース要素になりました。何を行うかを理解するために、「保存」と「キャンセル」、「送信」と「編集を続ける」などです。ユーザーがコンテキスト全体を読まずに提案されたオプションを見るだけで十分です。

上記の例の「オフラインモード」行は、アプリケーションがオフラインであることを示しています。 以下の例のスイッチは同じ意味を持っていますが、それを理解するにはコンテキストを見る必要があります。 スクリーンショット-Pandora

単体テストは、コードの予想される動作の確認にも役立ちます。コメントとして機能しますが、関連性が高いため、より信頼できる場合があります。確かに、彼らはまた、アセンブリを完了する必要があります。ただし、確立されたCIパイプラインの場合、テストは定期的に実行されるため、既存のコードを変更するときにこの手順をスキップできます。

理論的には、セキュリティは十分な理解から得られます。ユーザーがコードの動作を理解するとすぐに、安全に編集できます。実際には、開発者は普通の人だということを考慮する必要があります。私たちの脳は同じトリックを使い、怠け者でもあります。したがって、コードの理解に費やす労力が少ないほど、アクションの安全性は高まります。

読み取り可能なコードは、ほとんどのエラーチェックをコンピューターに渡す必要があります。これを行う方法の1つは、「アサート」デバッグチェックを使用することですが、アセンブリと起動も必要です。さらに悪いことに、ユーザーが境界線のケースを忘れた場合、「アサート」は役に立ちません。頻繁に忘れられている境界ケースをチェックする単体テストの方が効果的ですが、ユーザーが変更を加えたら、テストの実行を待つ必要があります。

要約すると、読み取り可能なコードは使いやすいはずです。そして-副作用として-それは美しく見えるかもしれません。

開発サイクルを高速化するために、コンパイラに組み込まれているエラーチェック機能を使用します。通常、このような場合、完全なアセンブリは不要であり、エラーはリアルタイムで表示されます。この機会をどのように活用しますか？一般的に、コンパイラチェックが非常に厳しくなる状況を見つける必要があります。たとえば、ほとんどのコンパイラは、「if」ステートメントがどの程度包括的に記述されているかを調べませんが、欠落している条件について「スイッチ」を注意深くチェックします。ユーザーが条件を追加または変更しようとした場合、以前の同様の演算子がすべて網羅されていれば安全です。そして、「ケース」条件を変更する瞬間に、コンパイラはチェックする必要がある他のすべての条件をマークします。

別の一般的な読みやすさの問題は、条件式でのプリミティブの使用です。この問題は、アプリケーションがJSONを解析するときに特に深刻です。文字列または整数の等価性を囲む「if」ステートメントを本当に追加したいからです。これはタイプミスの可能性を高めるだけでなく、可能な値を決定するユーザーのタスクを複雑にします。境界線のケースをチェックするとき、どの行が可能かと、2つまたは3つの別々のオプションだけとの間には大きな違いがあります。プリミティブが定数で固定されている場合でも、プロジェクトを時間通りに完了させようとすると、急いで1回急ぐ価値があり、任意の値が表示されます。ただし、特別に作成されたオブジェクトまたは列挙を使用する場合、コンパイラは無効な引数をブロックし、有効な引数の特定のリストを提供します。

同様に、ブールフラグのいくつかの組み合わせが許可されていない場合は、それらを単一の列挙に置き換えます。たとえば、次の状態になる可能性のあるコンポジションを考えてみましょう。バッファリングされ、完全にロードされ、再生されます。ロードおよび再生状態を2つのブールフラグとして想像する場合

 (loaded, playing)

コンパイラは無効な値の入力を許可します

 (loaded: false, playing: true)

そして、列挙を使用する場合

 (.buffering/.loaded/.playing)

無効な状態を示すことはできません。クライアント指向のインターフェースでは、デフォルトでは無効な設定の組み合わせを禁止する必要があります。しかし、アプリケーション内にコードを記述するとき、同じ保護を提供することを忘れることがよくあります。

無効な組み合わせは事前に無効になっています。 ユーザーは、どの構成に互換性がないかを考える必要はありません。 スクリーンショット-Apple

考慮されたユーザーパスに従って、最初と同じルールに到達しました。しかし、今では、それらを独立して策定し、状況に応じて変更できるという原則があります。これを行うには、次のことを自問します。

ユーザーが目的のコードを簡単に検索できますか？クエリに関連しない関数で検索結果が乱雑になりますか？
必要なコードを見つけたユーザーは、自分の動作の正確性をすばやく確認できますか？
開発環境は安全な編集とコードの再利用を提供しますか？

要約すると、読み取り可能なコードは使いやすいはずです。そして-副作用として-それは美しく見えるかもしれません。

ご注意

ブール変数は再利用する方が便利なように見えるかもしれませんが、この再利用オプションは互換性を意味します。たとえば、 タップ可能な フラグとキャッシュされたフラグを 考えてみましょう。これらのフラグは 、まったく異なるプレーンにある概念を表します。要素をクリックする機能とキャッシュの状態です。ただし、両方のフラグがブール値である場合、誤ってそれらを入れ替えて、コードの1行で重要な式を取得できます。これは、キャッシュが要素をクリックする機能に関連付けられていることを意味します。列挙を使用する場合、そのような関係を形成するために、使用される「測定単位」の変換のための明示的で検証可能なロジックを作成する必要があります。

翻訳者について

この記事はAlconostによって翻訳されました。

Alconostは、ゲーム、アプリケーション、およびサイトを70の言語にローカライズしています。ネイティブ翻訳者、言語テスト、APIを備えたクラウドプラットフォーム、継続的なローカリゼーション、プロジェクトマネージャー24時間365日、あらゆる形式の文字列リソース。

また、Google PlayおよびApp Storeの販売、画像、広告、トレーニング、ティーザー、エクスペラー、トレーラー用の広告およびトレーニングビデオも作成しています。

→ 続きを読む

コードの読みやすさ

コードを使用してインターフェイスを作成します。 しかし、コード自体はインターフェースです。

可読性とは何ですか？

どのコードが編集しやすいですか？

ご注意

More articles:

コードを使用してインターフェイスを作成します。しかし、コード自体はインターフェースです。