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

私はPythonで次のような練習をしています。 多項式は、指数によって指数が決定されるような係数のタプルとして与えられます。例：（9,7,5）は、9 + 7 * x + 5 * x ^ 2を意味します 与えられたxの値を計算する関数を書く 最近関数型プログラミングに夢中になっているので、私は書きました def evaluate1(poly, x): coeff = 0 power = 1 return reduce(lambda accu,pair : accu + pair[coeff] * x**pair[power], map(lambda x,y:(x,y), poly, range(len(poly))), 0) 私はそれを読めないと思うので、私は書きました def evaluate2(poly, x): power = 0 result = 1 return reduce(lambda accu,coeff …

10 functional-programming  readability  efficiency  clean-code  imperative-programming 

C ++には、引数の型が予期されたものでない場合に、パラメーターの型の一致するコンストラクターを自動的に呼び出す機能があります（適切な名前はわかりません）。 これの非常に基本的な例はstd::string、const char*引数付きのを期待する関数の呼び出しです。コンパイラーは、適切なstd::stringコンストラクターを呼び出すコードを自動的に生成します。 読みやすさに関しては、私が思うほど悪いのでしょうか。 次に例を示します。 class Texture { public: Texture(const std::string& imageFile); }; class Renderer { public: void Draw(const Texture& texture); }; Renderer renderer; std::string path = "foo.png"; renderer.Draw(path); いいですか？それとも行き過ぎですか？私がそれをするべきではない場合、どういうわけかClangまたはGCCにそれについて警告させることができますか？

10 c++  coding-style  readability  type-conversion  construction 

長いメソッドは一般的に悪いと考えられていますが、私のコードには理解しにくい長いメソッドがあります（50行以上）。内部の単一のステートメントはすでに50行を超えているため、これらのメソッドを読みやすくするのに苦労しています。その単一のステートメントを読み取るのは、ORMを使用してデータベースクエリを作成し、特定のジョブを実行することです。メソッド名に明記。ステートメントが複数の列に結合し、複数のwhereを適用し、複数の異なる列を選択して必要な文書化された出力形式を作成するため、ステートメントが非常に長い理由。 そのような読みにくいコードは悪いコードと見なされますか？同様に、複雑なアルゴリズムのコードを記述して、明確に名前が付けられたメソッドでラップされた読みにくいコードを生成した場合、そのコードは悪いコードですか？

9 readability 

C＃では、usingステートメントを使用して、ガベージコレクターを待たずにリソースを確定的な方法で破棄します。たとえば、次の目的で使用できます。 SQLコマンドまたは接続を破棄します。 ストリームを閉じ、ファイルのように基礎となるソースを解放し、 無料のGDI +要素、 等 これは、using処理するものが何もない場合にますます使用されていることに気付きましたが、呼び出し元usingが2つの個別のコマンドではなくブロックを書き込む方が便利な場合に使用します。 例： Stack Overflowチームによって作成されたMiniProfilerは、usingプロファイルするブロックを示すために使用します。 using (profiler.Step("Name goes here")) { this.DoSomethingUseful(i - 1); } 1つの代替アプローチは、2つのブロックを持つことです。 var p = profiler.Start("Name goes here"); this.DoSomethingUseful(i - 1); profiler.Stop(p); 別のアプローチはアクションを使用することです： profiler.Step("Name goes here", () => this.DoSomethingUseful(i - 1)); ASP.NET MVCもusingフォームに選択されています。 <% using (Html.BeginForm()) { %> <label for="firstName">Name:</label> <%= Html.TextBox("name")%> …

9 c#  .net  code-quality  readability 

一言で言えば、それを知らなかった人のために、Lisp関数/演算子/構造体はすべて次のように一律に呼び出されます： (function arg0 arg1 ... argN) では、Cのような言語では次のように表現します if (a > b && foo(param)) のようなLisp sexpに変換されます (if (and (> a b) (foo param))) 。物事がより現実的/複雑になるにつれて、対応するs式も私にとってはそうなります。 私はこれが主観的な質問である可能性が高いことを認識していますが、多くのLispハッカーにとって、これは常に対処しなければならないこの1つの小さな煩わしさでしょうか？ それとも、遅かれ早かれこの構文の欠如に慣れるのでしょうか？ いずれにせよ、特に長い目で見れば、読みやすさのためにブレークラインを追加すること（Cの同等のものを追加しないことがほとんどです）は良い考えですか？他の提案は大歓迎です。

9 lisp  readability 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 複数の言語を含むファイル（テンプレートファイルなど）で、インデントに関するベストプラクティスはありますか？ 私は主にこれを使用します： <div> IF FOO <div> <p>contents> </div> END FOO </div> 言語に関係なく、新しいブロックごとにインデントします。ただし、これにはいくつかの欠点があります。より複雑なファイルでは、どちらかの言語のインデントを壊す可能性があります： <div> IF FOO <div someattribute> ELSE <div otherattribute> END FOO <p>content</p> </div> </div> 私はこれが使用されるのを見たこともあります： <div> IF FOO <div> <p>contents> </div> END FOO </div> つまり。1つの言語のみインデントします。これには常に一貫性があるという利点がありますが、より複雑なファイルでは、ブロックが条件付きであることなど、一部の実装の詳細をほぼ完全に隠すことができます。 ここでの目標は、明らかに読みやすさを最大化することです。

8 language-agnostic  readability  indentation 

私がブール値（プロパティ）を持っている場合shouldAutoLogin、ゲッターに名前を付けるのが良いのでしょうgetShouldAutoLoginか、それとも単にshouldAutoLogin英語のように読めるようにするのですか？ 例： if(shouldAutoLogin){ ... } または if(getShouldAutoLogin){ ... }

8 readability  clean-code 

たとえば、最も高いランナー、最も速いランナー、最も軽いランナーを見つけるために必要な一連のランナーがあるとします。最も読みやすいソリューションは次のようになります： runners = getRunners(); tallestRunner = getTallestRunner(runners); fastestRunner = getFastestRunner(runners); lightestRunner = getLightestRunner(runners); ..各関数はランナーを反復処理し、最高の高さ、最高の速度、最低の重量を追跡します。ただし、配列を3回繰り返し処理することは、あまり良い考えではないようです。代わりにそれを行う方が良いでしょう： int greatestHeght, greatestSpeed, leastWeight; Runner tallestRunner, fastestRunner, lightestRunner; for(runner in runners){ if(runner.height > greatestHeight) { greatestHeight = runner.height; tallestRunner = runner; } if(runner.speed > ... } これは読みにくくありませんが、反復で抽出される情報の各部分にさらにロジックがあると、面倒になる可能性があります。 ここの中間点は何ですか？コードを論理ユニットに分割したまま、単一の反復のみを使用するにはどうすればよいですか？

8 design  code-quality  language-agnostic  readability 

私はジェネリックスを利用するコードをいくつか開発しています。私の指針となる原則の1つは、今日だけでなく、将来のシナリオでも使用できるようにすることでした。ただし、いくつかの同僚は、拡張性のために読みやすさを犠牲にしている可能性があると述べています。これを解決するために考えられる方法についてフィードバックを集めたかったのです。 具体的には、ここに変換を定義するインターフェースがあります。まず、項目のソースコレクションから開始し、各要素に変換を適用して、結果を宛先コレクションに保存します。さらに、宛先のコレクションを呼び出し元に返すことができるようにしたいのですが、コレクションの参照を使用するように強制するのではなく、宛先のコレクションに実際に提供したコレクションの種類を使用できるようにしたいと思います。 最後に、宛先のコレクション内のアイテムのタイプが、ソースのコレクション内のアイテムのタイプと異なるようにすることができます。これは、おそらく変換が行うためです。たとえば、私のコードでは、変換後にいくつかのソース項目が1つの宛先項目を構成しています。 これにより、次のインターフェースが生成されます。 interface Transform<Src, Dst> { <DstColl extends Collection<? super Dst>> DstColl transform( Collection<? extends Src> sourceCollection, DstColl destinationCollection); } インターフェースを適切にスーパータイプとサブタイプで使用できるようにするために、私はすべてがうまくいってJosh BlochのPECS原則（プロデューサー拡張、コンシューマースーパー）を適用しようとしました。最終結果は幾分怪物です。 さて、このインターフェースを拡張して、どういうわけかそれを特化できればいいのですが。たとえば、ソースアイテムのサブタイプとデスティネーションアイテムのスーパータイプをうまく使用する必要がない場合は、次のようにします。 interface SimpleTransform<Src, Dst> { <DstColl extends Collection<Dst>> DstColl transform( Collection<Src> sourceCollection, DstColl destinationCollection); } しかし、Javaでそれを行う方法はありません。私はこのインターフェースの実装を、恐怖で走るのではなく、他の人が実際に行うことを検討するようなものにしたいと考えています。私はいくつかのオプションを検討しました： 宛先のコレクションを返さないでください。変換を実行しても何も返されないことを考えると、奇妙に思えます。 このインターフェイスを実装する抽象クラスがありますが、パラメーターを使いやすいものに変換し、より単純なシグネチャを持つ別のメソッド "translateImpl（）"を呼び出します。これにより、実装者の認識の負担が少なくなります。しかし、インターフェイスをユーザーフレンドリーにするためだけに抽象クラスを作成しなければならないのは奇妙です。 拡張性を忘れ、よりシンプルなインターフェースを備えています。おそらく、それを宛先のコレクションを返さないことと組み合わせます。しかし、それは将来の私の選択肢を制限します。 どう思いますか？使用できるアプローチがありませんか？

8 java  readability  generics  extensibility 

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 5年前休業。 他のコードを読むとき、あなたは通常それを理解するのに問題がありますか、それとももっと普通に、他のコードが間違っている/非効率的/フォーマットが悪いなどについて質問することですか？ 最初の仕事でコーディングしたものを読んでいる人

8 readability 

タイトルに示されているように、ネストタイプ（クラスの列挙型や構造体など）は悪い習慣と見なされていますか？Visual Studioでコード分析を実行すると、次のメッセージが返されます。 警告34 CA1034：Microsoft.Design：タイプ 'ClassName.StructueName'をネストしないでください。または、外部から見えないようにアクセシビリティを変更します。 ただし、コード分析の推奨事項に従うと、単一のクラスにのみ適用されるか、またはそのクラスでのみ使用される可能性のある構造体および列挙型がアプリケーション内に多数存在する傾向があることがわかりました。そのような場合、その場合はタイプsinをネストするのが適切でしょうか、それともより良い方法がありますか？

8 design  c#  readability