タグ付けされた質問 「readability」

作成したコードが読みやすく、理解しやすく、保守しやすいことをどのように知ることができますか？作成者の観点からはもちろん、作成者がコードを作成および編集したため、最初からコードは読み取りおよび保守が可能です。しかし、私たちの職業がコードを測定できる客観的で定量化可能な標準がなければなりません。 これらの目標は、元の作者の専門家のアドバイスなしにコードを使用して次のことを実行できる場合に満たされます。 コードを読んで、基本的なレベルでロジックの流れを理解することができます。 入力、出力、アルゴリズムを含めるためにコードが何をしているのかをより深いレベルで理解することができます。 他の開発者は、バグ修正やリファクタリングなど、元のコードに意味のある変更を加えることができます。 元のコードを活用するクラスやモジュールなどの新しいコードを作成できます。 コードの品質を定量化または測定して、読み取り、理解、および保守が可能になるようにするにはどうすればよいですか？

336 code-quality  code-reviews  readability  maintainability 

私の上司は、下手なプログラマーがループ内で使用しているbreakとさりげなく言及していcontinueます。 それらが理にかなっているので、私は常にそれらを使用します。インスピレーションをお見せしましょう： function verify(object) { if (object->value < 0) return false; if (object->value > object->max_value) return false; if (object->name == "") return false; ... } ここでのポイントは、最初に関数が条件が正しいことを確認してから、実際の機能を実行することです。IMOループにも同じことが適用されます。 while (primary_condition) { if (loop_count > 1000) break; if (time_exect > 3600) break; if (this->data == "undefined") continue; if (this->skip == true) continue; ... …

191 coding-style  language-agnostic  syntax  readability  control-structures 

プログラマは皆、コードの可読性が機能する短い構文のワンライナーよりもはるかに重要であることに同意しているように見えますが、上級開発者がある程度の精度で解釈する必要があります-それはまさに正規表現が設計された方法のようです。これには理由がありましたか？ 私たちは皆、それselfDocumentingMethodName()がはるかに良いことに同意しe()ます。なぜ正規表現にも当てはまらないのですか？ 構造的な編成のない1行のロジックの構文を設計するのではなく、 var parse_url = /^(?:([A-Za-z]+):)?(\/{0,3})(0-9.\-A-Za-z]+)(?::(\d+))?(?:\/([^?#]*))?(?:\?([^#]*))?(?:#(.*))?$/; そして、これはURLの厳密な解析でさえありません！ 代わりに、基本的な例として、パイプライン構造を整理して読みやすくすることができます。 string.regex .isRange('A-Z' || 'a-z') .followedBy('/r'); 正規表現の非常に簡潔な構文は、最短の操作と論理構文以外にどのような利点がありますか？最終的に、正規表現の構文設計の可読性が低い特定の技術的な理由はありますか？

160 readability  regular-expressions 

通常、プライベートメソッドを使用して、クラス内の複数の場所で再利用される機能をカプセル化します。しかし、私は時々、それぞれが独自のプライベートメソッドの小さなステップに分割できる大きなパブリックメソッドを持っています。これにより、パブリックメソッドが短くなりますが、メソッドを読み取る人に別のプライベートメソッドにジャンプさせると読みやすさが損なわれるのではないかと心配しています。 これに関してコンセンサスはありますか？長いパブリックメソッドを使用する方が良いでしょうか、それとも各ピースが再利用できない場合でも、それらを小さなピースに分割する方が良いでしょうか？

139 coding-style  readability 

コードを書くときは、コードをできる限りクリーンで読みやすいものにするように常に心がけています。 ときどき、ラインを越えて、すっきりしたきれいなコードから少しugいコードに移行して、より速くする必要があるときがあります。 その線を横切るのはいつですか？

67 performance  optimization  quality  readability  maintainability 

そのため、先ほど見てみると、長い方法が悪い習慣であるというコメントがいくつかありました。 私は、長い方法が悪い（そして他の人からの意見が欲しい）ことにいつも同意するかどうかわかりません。 たとえば、オブジェクトをビューに送信する前にオブジェクトの処理を少し行うDjangoビューがあります。長いメソッドは350行のコードです。パラメータを処理するようにコードを作成しました。クエリセットの並べ替え/フィルタリングを行い、クエリが返したオブジェクトをビットごとに処理します。 そのため、処理は主に条件付き集計であり、データベースでは簡単に実行できない複雑なルールがあるため、メインループの外側で宣言された変数があり、ループ中に変更されます。 variable_1 = 0 variable_2 = 0 for object in queryset : if object.condition_condition_a and variable_2 > 0 : variable 1+= 1 ..... ... . more conditions to alter the variables return queryset, and context したがって、理論によれば、すべてのコードをより小さなメソッドに分解する必要があります。そのため、ビューメソッドは最大1ページの長さであると見なされます。 ただし、過去にさまざまなコードベースで作業していたため、あるメソッドから次のメソッドに絶えずジャンプして、その最も外側のメソッドを頭の中で保持する必要がある場合、コードが読みにくくなることがあります。 適切にフォーマットされた長いメソッドを使用すると、内部メソッドで隠されないため、ロジックをより簡単に確認できます。 コードをより小さなメソッドに分解することもできますが、多くの場合、2つまたは3つのことに使用される内部ループがあるため、より複雑なコード、または1つだけではなく2つまたは3つ（またはタスクごとに内部ループを繰り返すこともできますが、パフォーマンスが低下します）。 だから、長い方法が必ずしも悪いわけではない場合はありますか？メソッドを1つの場所でのみ使用する場合、メソッドを記述する場合は常にありますか？ 更新：1年以上前にこの質問をしたようです。 そこで、ここで（混合）応答の後にコードをリファクタリングし、メソッドに分割しました。これは、データベースから関連オブジェクトの複雑なセットを取得するDjangoアプリであるため、テストの引数が出ていません（おそらく、テストケースに関連するオブジェクトを作成するのにおそらく1年の大半を費やしていたでしょう。誰も文句を言う前の作業環境）。コードのその部分のバグを修正することは今やや簡単ですが、大したことではありません。 前 ： #comment 1 bit …

64 readability  methods 

理解しやすいもの、大きなブール文（非常に複雑なもの）、または述語メソッドに分解された同じ文（多くの余分なコードを読む） オプション1、大きなブール式： private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) { return propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue || repo.ParentId == propVal.ParentId && ((propVal.SecondaryFilter.HasValue && context.SecondaryFilter.HasValue && propVal.SecondaryFilter.Value == context.SecondaryFilter) || (!context.SecondaryFilter.HasValue && !propVal.SecondaryFilter.HasValue)); } オプション2、条件を述語メソッドに分割： private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) { return MatchesDefinitionId(context, propVal) && MatchesParentId(propVal) && (MatchedSecondaryFilter(context, propVal) …

63 c#  readability 

取得中に私のコードはここに見直さ使用しての問題constのキーワードを思い付きました。変数の読み取り専用動作を実装するために使用されることを理解しています。 私は、さまざまな状況が役に立つときに混乱する。 関数のプロトタイプを明確にするために使用すべきですか？ コード開発中のセキュリティ対策として使用する必要がありますか？ 実行時定数を宣言するために、さまざまな関数のスコープで使用する必要がありますか？ それはまったく使用されるべきですか？ これらの質問は、私が直面している混乱のほんの一例です。一般的な混乱は ときにする必要がありますconstCプログラミングで使用するキーワード？ Cでこのキーワードを使用することで得られるさまざまなタイプの利点は何ですか？ constキーワードを使用することの短所はありますか？ 私の質問の詳細にあるこれらすべての質問のために、この質問は広すぎるかもしれないと指摘されています。これらの質問は、主な質問に関する混乱を明確にするためだけのものであることを明確にしたかっただけです。 Cで変数にconstキーワードを使用するタイミングと目的は何ですか？ 言い換えることもできます const同じ長所と短所を備えたC` でのキーワードの適切な使用。

58 c  readability  patterns-and-practices  const 

ネストされた関数呼び出しのコーディングスタイルは次のとおりです。 var result_h1 = H1(b1); var result_h2 = H2(b2); var result_g1 = G1(result_h1, result_h2); var result_g2 = G2(c1); var a = F(result_g1, result_g2); 私は最近、次のコーディングスタイルが非常に使用されている部門に変更しました。 var a = F(G1(H1(b1), H2(b2)), G2(c1)); コーディングの私の方法の結果、クラッシュする機能の場合、Visual Studioは対応するダンプを開き、問題が発生した行を示すことができます（特にアクセス違反が心配です）。 最初の方法でプログラムされた同じ問題によるクラッシュの場合、どの関数がクラッシュを引き起こしたかを知ることができないのではないかと心配しています。 一方、1行に追加する処理が多いほど、1ページに表示されるロジックが多くなり、読みやすくなります。 私の恐怖は正しいのですか、それとも一般的には商業環境で好まれる何かが欠けていますか？可読性または保守性？ 関連するかどうかはわかりませんが、C ++（STL）/ C＃で作業しています。

57 c#  c++  coding-style  readability  maintainability 

コンセンサスは、開発対象のプラットフォームの規則に従う必要があるということです。見る： アンダースコアまたはラクダケース？ 命名規則：camelCase対underscore_case？ ただし、PHPはメソッドや関数（mysqli::set_local_infile_default、 など）についても、内部的には規則に厳密に従っていないようです（そこに驚くことはありませんPDOStatement::debugDumpParams）。ただし、関数名ではアンダースコアが支配的であるようです。 しかし、私が見つけることができなかったのはこれでした：PHPの変数の支配的な命名規則は何ですか？

51 php  naming  readability  camelcase 

良くも悪くも予約語になっている一般的な単語の意図的なスペルミスを含むコードをよく見ます： klassまたはclazzのためのクラス：Class clazz = ThisClass.class kount以下のためのカウント SQLで：count(*) AS kount 個人的には、これにより可読性が低下することがわかります。私自身の練習では、私はより良い名前が使用されていることができなかった、あまりにも多くのケースを発見していません- itemClassかrecordTotal。 クラスのJavaDocsの例は、パラメーターにこれを示しています。 public <U> Class<? extends U> asSubclass(Class<U> clazz) これは合理的なユースケースを示していますか？

45 coding-style  variables  readability  naming 

多くの場合、言語の構文で使用されない変数に名前を付ける必要がある場合は、名前を付け_ます。 私の考えでは、これにより混乱が減り、コード内の意味のある変数に集中できます。「目立たない、気にしない」効果を生み出すように、目立たないことがわかりました。 私がこれを行う場所の一般的な例は、SQLでサブクエリに名前を付けることです。 SELECT * FROM ( SELECT * FROM TableA JOIN TableB ON TableA.ColumnB = TableB.ColumnB WHERE [ColumnA] > 10 ) _ --This name is required, but never used here ORDER BY ColumnC 別の例は、使用されないループ変数です。 array = [[] for _ in range(n)] # Defines a list of n empty lists …

44 language-agnostic  naming  readability  variables 

特定のコンテキストでは、最小関数と最大関数で混乱します。 1つのコンテキストでは、関数を使用して2つの値のうちの大きい方または小さい方を取る場合、問題はありません。例えば、 //how many autographed CD's can I give out? int howManyAutographs(int CDs, int Cases, int Pens) { //if no pens, then I cannot sign any autographs if (Pens == 0) return 0; //I cannot give away a CD without a case or a case without a CD return min(CDs, …

40 design  functions  readability 

次のようなメソッドチェーンを使用する場合： var car = new Car().OfBrand(Brand.Ford).OfModel(12345).PaintedIn(Color.Silver).Create(); 次の2つのアプローチがあります。 次のように、同じオブジェクトを再利用します。 public Car PaintedIn(Color color) { this.Color = color; return this; } 次のCarように、すべてのステップでタイプの新しいオブジェクトを作成します。 public Car PaintedIn(Color color) { var car = new Car(this); // Clone the current object. car.Color = color; // Assign the values to the clone, not the original object. return …

37 coding-style  readability  method-chaining 

コードがどれだけ効率的でコードの可読性を犠牲にすべきですか？ たとえば、3行のコードを1行にまとめます。 私は読んでコードクラフト可読性が鍵であることをピートGoodliffeで。 あなたの考え？

37 code-quality  performance  optimization  readability