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

これらのメソッドを含むインターフェースを想定します： Car find(long id); List<Car> find(String model); このように名前を変更する方が良いですか？ Car findById(long id); List findByModel(String model); 実際、このAPIを使用する開発者は、初期find()メソッドの可能な引数を知るためにインターフェイスを調べる必要はありません。 だから私の質問はより一般的です：コードでオーバーロードされたメソッドを使用することの利点は何ですか？

14 design  naming  readability  method-overloading 

私は最近、特定のプロジェクトの特定のクラスにチェーンのメソッドを実装して、コードの可読性を向上させることを提案しました。「便利なだけでなく、セマンティクスのために流fluentなインターフェイスを実装すべきではない」という回答を得て、提案を打ち切りました。私は、流interfaceなインターフェースを提案しているのではなく、読みやすさとコーディングの快適さを改善するためにメソッド自体を連鎖させる（両方とも混同される可能性があります）と回答しました。 とにかく、これは、おそらく何も返さないはずのメソッド（セッターなど）で常に「this」を返すことで、悪い習慣を負わされる可能性があると考えさせられました。 私の質問は、前の慣習を適用することを悪い習慣や虐待とみなすことができるのか、なぜなのか、ということです。パフォーマンス上の欠点はないと思いますか？

14 architecture  coding-standards  readability  method-chaining 

値の検証を扱うクラスがたくさんあります。たとえば、RangeValidatorクラスは値が指定された範囲内にあるかどうかをチェックします。 すべてのバリデータクラスには2つのメソッドが含まれます：値is_valid(value)を返すTrueかFalse、値に応じて、ensure_valid(value)指定された値をチェックし、値が有効な場合は何もしないか、値が事前定義されたルールに一致しない場合は特定の例外をスローします。 現在、このメソッドに関連する2つの単体テストがあります。 無効な値を渡し、例外がスローされたことを確認するもの。 def test_outside_range(self): with self.assertRaises(demo.ValidationException): demo.RangeValidator(0, 100).ensure_valid(-5) 有効な値を渡すもの。 def test_in_range(self): demo.RangeValidator(0, 100).ensure_valid(25) 2番目のテストは、例外をスローすると失敗し、ensure_valid何もスローしないと成功しますが、assert内部にs がないという事実は奇妙に見えます。そのようなコードを読んだ人は、何もしていないように見えるテストがなぜあるのかをすぐに自問するでしょう。 これは、値を返さず、副作用のないメソッドをテストするときの現在のプラクティスですか？または、テストを別の方法で書き直す必要がありますか？または、単に私がやっていることを説明するコメントを入れますか？

13 unit-testing  exceptions  readability 

読むアイテムの数が不明なリーダーを繰り返し処理する必要があり、そのための唯一の方法は、最後まで読み続けることです。 これは多くの場合、無限ループが必要な場所です。 ブロック内のどこかに or ステートメントtrueがなければならないことを示すalways があります。breakreturn int offset = 0; while(true) { Record r = Read(offset); if(r == null) { break; } // do work offset++; } あり、二重ループ方式の読み取りが。 Record r = Read(0); for(int offset = 0; r != null; offset++) { r = Read(offset); if(r != null) { // do …

13 c#  code-quality  readability 

ほとんどのプログラミング言語では、変数にはPHPのような識別文字がありません。PHPでは、変数の前に$文字を付ける必要があります。 例; var $foo = "something"; echo $foo; ビジネスアプリケーション用の新しいスクリプト言語を開発していますが、ターゲットユーザーにはプログラミングのバックグラウンドがありません。これらの文字はコードを読みやすく、使いやすくしますか？ PHPを使用する理由の1つは、$PHPがないと、名前が関数参照か変数参照かを判断できないためです。これは、言語が関数への奇妙な参照を許可しているためです。したがって、この$シンボルは、パーサーが名前空間を分離するのに役立ちます。 パーサーにはこの問題はありません。したがって、私の質問は読みやすさと使いやすさだけです。私はPHPで長年コーディングしてきたので、これを見る$fooと、これを変数として簡単に識別できます。私はこの識別子にバイアス設定を与えているだけですか？

13 programming-languages  readability 

私はClojureを初めて使用します。書いたコードは理解できますが、後で理解するのが難しくなります。 括弧を一致させることが難しくなります。 さまざまな状況での命名規則とインデントに関して従うべき一般的な規則は何ですか？ たとえば、理解するためにサンプルの非構造化例を作成しましたが、2回目には完全に判読できません。 (defn f [{x :x y :y z :z [a b c] :coll}] (print x " " y " " z " " a " " b " " c)) 構造化を解除する場合、パラメータレベルで直接行うか、letフォームを開始してから続行する方が良いでしょうか？

13 readability  clojure 

かなり長いプロパティ名でifステートメントを書いていたところ、この問題に遭遇しました。 次のようなifステートメントがあるとします。 if(_someViewModelNameThatIsLong.AnotherPropertyINeedToCheck == someValue && !_someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant) { //Do something } 2番目のプロパティはブール型であり、次のようなステートメントを持つことは意味がありません if(boleanValue == true) 否定を強調するより良い方法はあり!ますか？私には、コードを読み取るときにこれが簡単に監視され、デバッグで問題が発生する可能性があるようです

13 readability 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 私はこれに興味があります。関数型言語を学ぶ前に思い出したので、それらはすべて恐ろしく、ひどく、ひどく読めないと思っていました。Haskellとf＃を知ったので、少ないコードを読むのに少し時間がかかりますが、その小さなコードは命令型言語での同等の量よりもはるかに多いので、純益のように感じ、私は極端ではありません機能的に実践。 ここに私の質問があります。私は、OOPの人々から、機能的なスタイルはひどく読めないと常に聞いています。これが事実であり、自分を欺いているのか、または関数型言語を習得するのに時間がかかったのであれば、スタイル全体がOOPよりも読みにくくなるのではないかと思います。 誰かが証拠を見たり、逸話を手に入れたりして、おそらくこれを言うのに十分な頻度で行っていますか？機能的に実際に書くのが読みにくい場合は、使い続けたくありませんが、そうなのかどうかはわかりません。

13 object-oriented  functional-programming  readability 

私の理解では、[Flag]enumは通常、個々の値が相互に排他的でない組み合わせ可能なものに使用されるということです。 例えば： [Flags] public enum SomeAttributes { Foo = 1 << 0, Bar = 1 << 1, Baz = 1 << 2, } どこにどんなSomeAttributes値がの組み合わせとすることができるFoo、BarとBaz。 より複雑で実際のシナリオでは、列挙型を使用して以下を記述しDeclarationTypeます。 [Flags] public enum DeclarationType { Project = 1 << 0, Module = 1 << 1, ProceduralModule = 1 << 2 | Module, ClassModule = 1 …

12 c#  .net  readability  enum 

私は単一責任原則（SRP）に準拠し、コードの繰り返しを省略しようとします。しかし、少なくとも意味のある名前付きメソッドへの抽出に抵抗する呼び出しのコードブロックにすぎないコードの繰り返しがある場所がしばしばあります。 DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); そのようなコードをメソッドに抽出する最良の方法とその命名方法は何ですか？

11 refactoring  readability  single-responsibility  code-reuse 

私は最近、Javaの中規模プロジェクトをリファクタリングして、戻って単体テストを追加しました。シングルトンとスタティックをモックするのがどれほど苦痛であるかに気付いたとき、私はついにこれまで読んでいたものをついに「手に入れました」。（私は経験から学ぶ必要がある人の一人です。まあ。） ですから、Springを使用してオブジェクトを作成し、それらをワイヤリングするようになったのでstatic、左右のキーワードを取り除きました。（潜在的にそれをモックしたい場合、Math.abs（）と同じ意味で本当に静的ではありませんよね？）問題は、staticメソッドが依存していないことを示すために使用する習慣になったことです任意のオブジェクト状態。例えば： //Before import com.thirdparty.ThirdPartyLibrary.Thingy; public class ThirdPartyLibraryWrapper { public static Thingy newThingy(InputType input) { new Thingy.Builder().withInput(input).alwaysFrobnicate().build(); } } //called as... ThirdPartyLibraryWrapper.newThingy(input); //After public class ThirdPartyFactory { public Thingy newThingy(InputType input) { new Thingy.Builder().withInput(input).alwaysFrobnicate().build(); } } //called as... thirdPartyFactoryInstance.newThingy(input); だから、ここが微妙な感覚になります。古い方法が好きだったのは、Math.sin（x）と同様に、ThirdPartyLibraryWrapper.newThingy（x）が毎回同じ方法で同じことをしたことを大文字が教えてくれたからです。オブジェクトに要求することをオブジェクトがどのように行うかを変更するオブジェクトの状態はありません。ここで私が検討しているいくつかの可能な答えがあります。 誰もこのように感じていないので、私には何か問題があります。たぶん、オブジェクト指向のやり方を実際に内部化していないだけかもしれません！たぶん私はJavaで書いていますが、FORTRANなどで考えています。（私がFORTRANを書いたことがないので、どれが印象的でしょう。） コードについての推論を目的として、不変性の一種のプロキシとして静的性を使用しているのかもしれません。そうは言っても、ステートフルなものとそうでないものを知るためにコードを維持するために、コードに手がかり はありますか？ おそらく、良いオブジェクトのメタファーを選択した場合、これは無料で提供されるはずです。例えばthingyWrapper、Thingyそれ自体が可変である可能性のあるラップされた状態に依存していないように聞こえます。同様に、thingyFactoryサウンドは不変である必要がありますが、作成時に選択されるさまざまな戦略を持つことができます。

11 coding-standards  readability  coding-style  static-methods 

どちらがより保守性が高いと考えられますか？ if (a == b) c = true; else c = false; または c = (a == b); Code Completeで調べてみましたが、答えが見つかりません。 最初のほうが読みやすいと思います（文字通り大声で読むことができます）。2番目の方法は確かに理にかなっており、コードを削減しますが、C＃開発者にとってそれが保守可能であるかどうかはわかりません（たとえば、このイディオムはPythonでもっと見られると思います）。

11 .net  code-quality  readability  maintainability  clean-code 

私はデルファイでプロジェクトを進めており、アプリケーションのインストーラーを作成しています。主に3つの部分があります。 PostgreSQLのインストール/アンインストール myapplication（myapplicationのセットアップはnsiを使用して作成されます）インストール/アンインストール。 スクリプト（バッチファイル）を使用してPostgresでテーブルを作成します。 すべてがうまくスムーズに実行されますが、何かが失敗した場合は、 このようにプロセスのすべてのステップをLogToFileするLogToFilegerを作成しました LogToFileToFile.LogToFile('[DatabaseInstallation] : [ACTION]:Postgres installation started'); 関数LogToFileToFile.LogToFile()これは、内容をファイルに書き込みます。これはうまく機能していますが、問題は、コードのどこでも関数呼び出しを見るだけでコードを読むことが難しくなっているため、コードが台無しになっていることLogToFileToFile.LogToFile()です 例 if Not FileExists(SystemDrive+'\FileName.txt') then begin if CopyFile(PChar(FilePathBase+'FileName.txt'), PChar(SystemDrive+'\FileName.txt'), False) then LogToFileToFile.LogToFile('[DatabaseInstallation] : copying FileName.txt to '+SystemDrive+'\ done') else LogToFileToFile.LogToFile('[DatabaseInstallation] : copying FileName.txt to '+SystemDrive+'\ Failed'); end; if Not FileExists(SystemDrive+'\SecondFileName.txt') then begin if CopyFile(PChar(FilePathBase+'SecondFileName.txt'), PChar('c:\SecondFileName.txt'), False) then LogToFileToFile.LogToFile('[DatabaseInstallation] …

11 code-quality  readability  logging 

この質問にはすぐに主観的なフラグが立てられると思いますが、どちらが良いと思いますか： double volume(double pressure, double n_moles, double temperature) { return n_moles * BOLTZMANN_CONSTANT * temperature / pressure; } または double volume(double P, double n, double T) { return n*R*T/P; } 言い換えると、いくつかの式を実装する関数は、その式の表記法に従うべきですか、それともより詳細な名前を使用する必要がありますか？

11 math  coding-style  readability 

これらのどれが保守性に優れていますか？ if (byteArrayVariable != null) if (byteArrayVariable .Length != 0) //Do something with byteArrayVariable または if ((byteArrayVariable != null) && (byteArrayVariable.Length != 0)) //Do something with byteArrayVariable 私は2番目のものを読み書きすることを好みますが、そのようなことを行うと保守性が悪くなることを完全なコードで読んだことを思い出します。 これはif、最初の部分がfalseであり、すべての言語がそれを行うわけではない場合、2番目の部分を評価しないように言語に依存しているためです。（nullで評価された場合、2番目の部分は例外をスローしますbyteArrayVariable。） それが本当に心配なのかどうかわからないので、質問に対する一般的なフィードバックをお願いします。 ありがとう。

11 programming-practices  coding-standards  maintenance  readability