タグ付けされた質問 「coding-style」

プライベートメソッドがプライベートデータにアクセスするためにパブリックルートを使用する必要があるのはいつですか？たとえば、この不変の「乗数」クラスがある場合（少し工夫されていると思います）。 class Multiplier { public: Multiplier(int a, int b) : a(a), b(b) { } int getA() const { return a; } int getB() const { return b; } int getProduct() const { /* ??? */ } private: int a, b; }; 実装できる方法は2つありますgetProduct。 int getProduct() const { return a * b; …

11 programming-practices  coding-style  access-control 

私はUI開発は初めてですが、CSSがどのように機能するかについて非常に不快に感じています。 私のユースケースは、特定のスタイルをdivページの特定の内部に適用したかったということです。 CSSの試行： div.class1 { font: normal 12px arial, helvetica, sans-serif; font-color: #f30; } div.class1 div.class2 { border: 1px solid #f30; } より少ない試み： @red: #f30; @font-family: arial, helvetica, sans-serif; div.class1 { font: normal 12px @font-family; font-color: @red; div.class2 { border: 1px solid @red; } それは繰り返すようにあなたを強制ので、CSSのバージョンでは、バグを誘発することができます#f30＆div.class2あなたは階層変数の再利用を実現しようとするたびに。 私の質問： なぜCSSが物事を難しくしているのですか？ LESSは特別なことは何もしません-明らかな改善を行い、CSSに変換するだけですか？ そのような冗長なコーディングスタイルを促進するために、CSSはユーザーを動機づけたいと考えています。 CSSはLESSと同じであると強く信じています。確かに、CSSで物事がそのように行われる理由の明らかな利点を見落としています。これはレガシーな問題だと思っていましたが、CSS3でこれを解決しようとする試みが見られなかったときは驚きました。 …

11 coding-style  css  ui  css3 

私は最近、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 

正規表現にコメントするための一般的な慣行はありますか：正規表現の別の部分を参照するインラインコメントまたはすべての表現に対する一般的なコメントですか？

11 documentation  coding-style  comments 

bodyタグへのスタイルの適用はページ全体に適用されるため、 body { font-family: Verdana } ページ全体に適用されます。これは次の方法でも実行できます * {font-family: Verdana} これはすべての要素に適用されるため、同じ効果があるようです。 最初の例ではスタイルがページ全体の1つのタグに適用され、2番目の例では各HTML要素にフォントが適用されるという原則を理解しています。私が求めているのは、それを行う際の実際的な違いは何か、意味するものは何か、そして他のものを使用することにつながる理由、状況、またはベストプラクティスは何かということです。 副作用の1つは確かに速度（+1ロブ）です。機能の面でどちらかを選択する実際の理由に最も興味があります。

11 design-patterns  coding-style  html  css 

「C ++ Coding Standards」を読んでいて、この行がありました： 変数は状態を導入するため、可能な限り短いライフタイムで、できるだけ少ない状態を処理する必要があります。 変異するものは最終的に状態を操作しませんか？できるだけ少ない状態に対処する必要があるとはどういう意味ですか？ C ++などの不純な言語では、状態管理は本当にあなたがしていることではありませんか？そして、変数の寿命を制限する以外に、できるだけ少ない状態に対処する他の方法は何ですか？

11 c++  coding-style  programming-languages  state 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 PythonまたはJavascriptを使用している場合は、改行がコードを途中で終了させないように、常に前の行の最後にバイナリ演算子を配置する必要があります。エラーをキャッチするのに役立ちます。 しかし、CまたはC ++では、これは問題ではないので、私は疑問に思っています： 最初のバージョンよりも2番目のバージョンを好む理由はありますか？ return lots_of_text + 1; 対 return lots_of_text + 1; （たとえば、そのうちの1つは他の種類のエラーの防止に役立ちますか？または、そのうちの1つはより読みやすいと見なされますか？）

11 c++  coding-style 

今日は同僚と話していました。2つの異なるプロジェクトのコードに取り組んでいます。私の場合、自分のコードに取り組んでいるのは私だけです。彼女の場合、複数の人が同じコードベースで作業します。これには、かなり定期的に（8〜12か月ごとに）出入りする生協学生も含まれます。彼女は自分のコメントに寛大であり、あちこちにそれらを置いていると言った。彼女の推論は、コードの大部分が彼女によって書かれておらず、彼女以外の誰かによって変更される可能性があるため、物事がどこにあり、何をしているのかを思い出すのに役立つということです。その間、私はコード内のコメントを最小限に抑え、明白でない回避策またはバグがある場所にのみコメントを配置しようとします。ただし、コード全体をよりよく理解し、コードをより直接制御できます。 そのコメントでの私の意見は最小限であり、コードはストーリーの大部分を伝えるべきですが、彼女の推論も理にかなっています。彼女の推論に欠陥はありますか？コードが乱雑になる場合がありますが、短期から中期に多くの人が作業している場合、最終的には非常に役立ちます。

11 coding-style  team  comments 

これは関連しているQ： 返品後の作業を行うためのfinally節の使用は、スタイルが悪い/危険ですか？ 参照されるQでは、最終的に使用されるコードは、使用される構造とプリフェッチの必要性に関連しています。私の質問は少し異なりますが、より多くの聴衆にとって密接な関係があると思います。私の特定の例はC＃winformアプリですが、これは最終的にC ++ / Javaの使用にも適用されます。 私は、ブロックに例外や例外処理/クリーンアップに関係のないコードがたくさんあるtry-catch-finallyブロックにかなり気付いています。そして、例外と処理に密接に関連するコードで非常にタイトなtry-catch-finallyブロックを作成するという私のバイアスを認めます。ここに私が見ているもののいくつかの例があります。 tryブロックには、スローされる可能性のあるコードに至るまでの多くの予備的な呼び出しと変数が設定されます。ロギング情報は、セットアップを取得し、tryブロックでも実行されます。 最後に、ブロックはform / module / controlのフォーマット呼び出し（catchブロックで表されるように、アプリが終了しようとしているにもかかわらず）を持ち、パネルなどの新しいオブジェクトを作成します。 大体： methodName（...） { 試してみる { //メソッドの多くのコード... //スローできるコード... //メソッドとリターンのためのより多くのコードを... } catch（何か） {//例外を処理する} 最後に { //例外によるいくつかのクリーンアップ、クローズ //作成されたもののためのより多くのコード（例外がスローされる可能性があることを無視）... //さらにオブジェクトを作成します } } コードは機能するため、何らかの価値があります。それはうまくカプセル化されておらず、ロジックは少し複雑です。私は（苦労して）コードを移動したりリファクタリングしたりするリスクに精通しているので、私の質問は、同様に構造化されたコードに関する他の人の経験を知りたいということになります。 悪いスタイルは変更を加えることを正当化しますか？同様の状況で誰かがひどくやけどをしたことがありますか？その悪い経験の詳細を共有してくれませんか？私が過剰に反応していて、スタイルがそれほど悪くないので、それを残してください？物事を片付けることのメンテナンスの利点を得る？

11 design  exception-handling  coding-style 

この例を考えてみましょう： ウェブサイトを持っています。これにより、ユーザーは投稿（何でも可能）を作成し、投稿を説明するタグを追加できます。コードには、投稿とタグを表す2つのクラスがあります。これらのクラスをPostおよびと呼びましょうTag。 Post投稿の作成、投稿の削除、投稿の更新など Tagを処理します。タグの作成、タグの削除、タグの更新などを処理します。 欠落している操作が1つあります。タグと投稿のリンク。私は誰がこの手術をすべきかと格闘しています。どちらのクラスにも等しく適合する可能性があります。 一方では、PostクラスにTagaをパラメーターとして受け取り、タグのリストに格納する関数を含めることができます。一方、Tagクラスが取る関数可能性がありPost、パラメータとして及びリンクTagにしますPost。 上記は私の問題の一例です。私は実際には、すべて類似した複数のクラスでこれに直面しています。それは両方に等しく適合する可能性があります。実際に両方のクラスに機能を配置するのではなく、この問題を解決するのに役立つ規則やデザインスタイルが存在します。私は1つを選ぶだけでは足りないものがあるはずだと思いますか？ たぶん両方のクラスに入れるのが正しい答えでしょうか？

11 design  design-patterns  coding-style  single-responsibility 

私は最近、多くの人が眉をひそめるかもしれないと知っている習慣を身につけましたが、最終的には、単一の（時には）反復的な方法の構造ではなく、グローバルなコード構造に目を向けるのに役立ちます：次のような1行のステートメント textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!"; とは対照的に textBox1.Text = "Something!"; textBox2.Text = "Another thing!"; textBox3.Text = "Yet another thing!"; コードの全体的な「美しさ」を維持し、プログラム構造を簡単に追跡できるようにするために、繰り返し行うタスクでそれを使用しますが、それは良い習慣ではないことを認めます。私は実際にそれを頻繁に使用するので、これについてあなたの考えを知りたいと思います。また、私のコードを保守しなければならない人は誰でもこのアプローチに問題があると思いますか？

11 coding-style 

この質問にはすぐに主観的なフラグが立てられると思いますが、どちらが良いと思いますか： 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 

関数から複数の値を返したい場合があります。 これは通常 Javaでどのように行われますか？ 1つのオプションは、リストまたはタプルを返すこのPythonスニペットのような配列を使用することです。 value, success = read_unreliably() if success: print value 別のオプションは、次のJavaScriptの例のように、ハッシュ/辞書を返すことです。 var result = readUnreliably() if (result.success) { alert(value); } もう1つは、このJavaの例のように、この目的のためだけにカスタムオブジェクトを作成することです。 ReadUnreliablyResult result = readUnreliably() if (result.getSuccess()) { System.out.println(result.getValue()); } もちろん、物事をやり取りする代わりに、いくつかのグローバル変数を使用して必要なものを保存することもできますが、それはオプションではないと言ってみましょう。

11 java  coding-style 

かなり前にADAで多くのプログラムを作成しましたが、関数を呼び出すときに引数に名前を付けるのは正常でした-SomeObject.DoSomething（SomeParameterName => someValue）; C＃が名前付き引数をサポートするようになったので、引数の意味が明らかでない場合にこの習慣に戻すことを考えています。 引数の意味が常に明らかであると主張するかもしれませんが、ブール引数を持ち、呼び出し元が「true」または「false」を渡す場合、名前で値を修飾すると、呼び出しサイトが読みやすくなります。 contentFetcher.DownloadNote（note、manual：true）; trueまたはfalse（この場合は手動、自動）を使用する代わりにEnumを作成できると思います。 コードを読みやすくするために、時々名前付き引数を使用することについてどう思いますか？

11 coding-style 

Java 8では、関数型インターフェイスの概念と、関数型インターフェイスを取るように設計された多数の新しいメソッドが追加されました。これらのインターフェースのインスタンスは、メソッド参照式（例SomeClass::someMethod）とラムダ式（例(x, y) -> x + y）を使用して簡潔に作成できます。 同僚と私は、どちらのフォームを使用するのが最適かについて意見が異なります（この場合、「最適」は、「最も読みやすい」と「標準的な慣行に最も近い」に要約されます。同等）。具体的には、次のすべてが当てはまる場合です。 問題の関数は単一のスコープの外では使用されません インスタンスに名前を付けると、読みやすさが向上します（たとえば、ロジックが何が起こっているかを一目で確認できるほど単純であるのとは対照的） ある形式が他の形式よりも好まれるプログラミング上の理由は他にはありません。 この問題についての私の現在の意見は、プライベートメソッドを追加し、それをメソッド参照で参照することが、より優れたアプローチであるというものです。これはこの機能がどのように使用されるように設計されているかのように感じられ、メソッド名とシグネチャを介して何が起こっているかを伝える方が簡単に思われます（たとえば、「boolean isResultInFuture（Result result）」は明らかにブール値を返すと言っています）。また、クラスの将来の拡張で同じチェックを利用したい場合に、プライベートメソッドを再利用しやすくしますが、機能インターフェイスラッパーは必要ありません。 私の同僚の好みは、インターフェイスのインスタンスを返すメソッドを用意することです（たとえば、 "Predicate resultInFuture（）"）。私には、この機能の使用方法が完全ではないように感じられ、少し不格好に感じられ、名前を付けることで意図を実際に伝えるのが難しいように思われます。 この例を具体的にするために、異なるスタイルで記述された同じコードを次に示します。 public class ResultProcessor { public void doSomethingImportant(List<Result> results) { results.filter(this::isResultInFuture).forEach({ result -> // Do something important with each future result line }); } private boolean isResultInFuture(Result result) { someOtherService.getResultDateFromDatabase(result).after(new Date()); } } …

11 java  coding-style  naming  methods  lambda