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

「pythonic」のグーグル検索を行うと、幅広い解釈が明らかになります。ウィキペディアのページは言います： Pythonコミュニティの一般的な新語法はpythonicです。これは、プログラムスタイルに関連した幅広い意味を持つことができます。コードがpythonicであると言うことは、Pythonのイディオムをうまく使用していること、自然である、または言語が流であることを示すことです。同様に、インターフェイスまたは言語機能についてpythonicであると言うことは、Pythonイディオムとうまく機能し、その使用が他の言語とうまく噛み合うと言うことです。 「unpythonic」という用語についても説明します。 対照的に、非Pythonコードの特徴は、PythonでC ++（またはLisp、Perl、Java）コードを記述しようとすることです。つまり、別の言語の形式の慣用的な翻訳ではなく、大まかな転写を提供します。pythonicityの概念は、読みやすさのPythonのミニマリスト哲学と密接に結びついており、「それを行うには複数の方法があります」アプローチを避けています。判読不能なコードまたは理解できないイディオムは、Pythonではありません。 「pythonic」という用語の意味は何ですか？実際にそれを効果的に適用する方法を学ぶにはどうすればよいですか？

46 code-quality  coding-style  python 

私は視覚障害者です。メガネをかけると運転には十分ですが、フォントサイズでは快適に作業できますが、一度に表示できるのは100文字の15行のみです。これは私のコーディングスタイルに影響を与えました。 私がやっていることの1つは、短い関数を書くことです。私のコードは良い名前のこれらの短い関数がより高いレベルの関数を非常に読みやすくするので良いレビューを得る傾向がありますが、パフォーマンスの高い状況では一部の人々は変数をいくつかのレイヤーに渡してスタックに占めるスペースについてコメントします処理。 2番目に行うことは、クラスをファイル間で分割して短いファイルを作成することです。これにより、スクロール距離が短くなり、関連する機能に到達します。組織によっては、ファイルを別のモニターに配置して一緒に見ることができる場合があります。 これらのプラクティスはどちらも、ほとんどのコーディングスタイルでドキュメント化が必要なドキュメント化可能な単位になります。これにより、ファイルの長さと関連する関数間の距離が長くなり、問題がさらに悪化します。 現在Visual Studioを使用しています。VisualStudioでは、関数とコメントブロックレベル（頻繁に使用します）でコードを折りたたみますが、Notepad ++のようにブラケットレベルでは折りたたみません。優れたコード折りたたみを提供するエディターには、VSのすべてのインテリセンス機能がありません。VSでリージョンを使用することもできますが、10行ごとに使用すると、非常に煩雑になります。折り畳みは、コードの別の機能に取り組んでいるときに、完成したコードを見えなくするのに役立つことがあります。 誰もがコードの可視性を制限するのに役立つより良いコーディング方法を推奨できますか？

45 coding-style 

次のSQLクエリは同じです。 SELECT column1, column2 FROM table1, table2 WHERE table1.id = table2.id; SELECT column1, column2 FROM table1 JOIN table2 ON table1.id = table2.id; そして確かに、私が試したすべてのDBMSで同じクエリプランが得られます。 しかし、時々、一方が他方よりも間違いなく優れているという意見を読んだり聞いたりします。当然、これらの主張は説明によって実証されることはありません。 私が働いている場所では、2番目のバージョンは他の開発者の大多数に好まれているようです。そのため、驚きを最小限に抑えるために、このスタイルに向かう傾向もあります。しかし、私の心の中で、私は本当に最初のものを考えています（それが最初にそれを学んだ方法だからです）。 これらの形式の1つは、他の形式よりも客観的に優れていますか？そうでない場合、一方を他方よりも使用する理由は何でしょうか？

45 sql  coding-style 

良くも悪くも予約語になっている一般的な単語の意図的なスペルミスを含むコードをよく見ます： 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 

私はLinqの同僚と議論しています。ここにコピーします： 同僚：ここで正直に話しましょう。Linq構文はダメです。わかりにくく直感的ではありません。 私：ああ、T-SQLよりも混乱しますか？ 同僚：ええ、はい。 私：それは同じ基本的なパーツ、select、where、fromを持っています 同僚：私にとって、Linqはリレーショナル+ OOのろくでなしです。同僚：誤解しないでください。信じられないほど強力ですが、SQLを再利用してオブジェクトコレクションを使用しました。 私は、Linq + Lamdaを使用することは非常に強力であり（彼は同意します）、またコードを読みやすくします（彼はその点で同意しません）と思います。 pickFiles = from f in pickFolder.GetFiles("*.txt") where ValidAuditFileName.IsMatch(f.Name) select f; または var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>() where s.FileName == f.FullName && s.DocumentType != "Unknown" select s; または（VBコードはこちら） Dim notVerified = From image In images.AsParallel Group Join verifyFile In …

43 coding-style  linq  lambda 

if可能な場合は、長い巻き取り条件を避ける必要がありますが、ときどき私たち全員がそれらを書くことになります。たとえそれが非常に単純な条件であっても、関係するステートメントは時々非常に冗長であるため、条件全体が非常に長くなります。それらをフォーマットする最も読みやすい方法は何ですか？ if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) { thud(); } または if ( FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy ) { thud(); } または if (FoobarBaz::quxQuux(corge, grault) || !garply(waldo) || fred(plugh) !== xyzzy) { thud(); } または thudable = FoobarBaz::quxQuux(corge, grault); thudable ||= !garply(waldo); thudable …

43 coding-style  conditions 

よると、原始的強迫観念ではないコードのにおいがある場合は？、Stringオブジェクトの代わりに郵便番号を表すZipCodeオブジェクトを作成する必要があります。 しかし、私の経験では、私は見たいです public class Address{ public String zipCode; } の代わりに public class Address{ public ZipCode zipCode; } 後者では、プログラムを理解するためにZipCodeクラスに移動する必要があると思うからです。 そして、私はすべてのプリミティブデータフィールドがあるかのように感じているクラスに置き換えた場合、私は定義を参照するために多くのクラス間を移動する必要があると考えているから苦しみヨーヨー問題（アンチパターン）。 そこで、ZipCodeメソッドを新しいクラスに移動したいと思います。例えば： 古い： public class ZipCode{ public boolean validate(String zipCode){ } } 新着： public class ZipCodeHelper{ public static boolean validate(String zipCode){ } } そのため、郵便番号を検証する必要があるのはZipCodeHelperクラスに依存するだけです。そして、私は原始的な強迫観念を保持する別の「利点」を見つけました。たとえば、文字列列zipCodeを持つアドレステーブルなど、クラスがシリアル化された形式のように見えます。 私の質問は、「ヨーヨーの問題を回避する」（クラス定義間を移動する）が「原始的な強迫観念」を許可する正当な理由ですか？

42 object-oriented  coding-style 

インターフェースはめったに使用せず、他のコードでは一般的です。 また、コード内でめったにサブクラスとスーパークラスを作成しません（独自のクラスを作成します）。 それは悪いことですか？ このスタイルを変更することをお勧めしますか？ このスタイルには副作用がありますか？ これは、私が大規模なプロジェクトに取り組んだことがないためですか？

40 programming-practices  coding-style  interfaces 

それで、私は数年前からプログラミングをしていて、最近ReSharperをもっと使い始めました。ReSharperが私に常に示唆していることの1つは、「 'if'ステートメントを逆にして入れ子を減らす」ことです。 このコードがあるとしましょう： foreach (someObject in someObjectList) { if(someObject != null) { someOtherObject = someObject.SomeProperty; } } そして、ReSharperは私がこれを行うことを提案します： foreach (someObject in someObjectList) { if(someObject == null) continue; someOtherObject = someObject.SomeProperty; } ReSharperは、ネストがどれだけ進んでいるかに関係なく、IFを反転させることを常に提案するようです。この問題は、少なくともいくつかの状況でネストするのが好きだということです。私にとっては、特定の場所で何が起こっているのかを読み、理解するのが簡単に思えます。これは常にそうではありませんが、私は時々より快適なネストを感じます。 私の質問は、個人的な好みや読みやすさ以外に、ネストを減らす理由はありますか？パフォーマンスの違いや、私が気付いていない他の何かがありますか？

39 .net  coding-style  code-quality  clean-code  resharper 

動作を決定するためにブール値パラメーターを使用するのは間違っていますか？、ブールパラメータを使用して動作を決定することを避けることの重要性を知っています。たとえば： 元のバージョン public void setState(boolean flag){ if(flag){ a(); }else{ b(); } c(); } 新しいバージョン： public void setStateTrue(){ a(); c(); } public void setStateFalse(){ b(); c(); } しかし、動作の代わりにブール値パラメーターを使用して値を決定する場合はどうでしょうか？例えば： public void setHint(boolean isHintOn){ this.layer1.visible=isHintOn; this.layer2.visible=!isHintOn; this.layer3.visible=isHintOn; } 私はisHintOnフラグを削除し、2つの別個の関数を作成しようとしています。 public void setHintOn(){ this.layer1.visible=true; this.layer2.visible=false; this.layer3.visible=true; } public void setHintOff(){ this.layer1.visible=false; this.layer2.visible=true; this.layer3.visible=false; } …

39 design  object-oriented-design  coding-style  parameters  boolean 

整数リテラルにアンダースコアを許可しない言語では、10億の定数を作成することをお勧めしますか？たとえば、C ++の場合： size_t ONE_BILLION = 1000000000; 確かに、100のような小さな数値に対して定数を作成するべきではありません。しかし、9個のゼロがあると、次のようなコードにゼロを残したり、余分なものを追加したりするのは間違いなく簡単です： tv_sec = timeInNanosec / 1000000000; tv_nsec = timeInNanosec % 1000000000;

39 coding-style 

（私は（プログラミング言語ではなく）HTML / CSSコードについて話しているが、プログラマーと同じ問題に直面していると思う。） 私はチームのシニアフロントエンドデザイナーであり、後輩の成果を厳しい締め切りで頻繁に作り直す必要があります。 私は2つの問題に直面しています： それらのコーディングスタイルは少し複雑です。 美学は良くありません。 彼らのコーディングスタイルは、適切な慣習/標準がない混合バッグです。私は、コードをクリーンアップするか、単にコードを処理する（それらがどのように動作するかをコピーする）ことで引き裂かれます。 私は悪い習慣を学ぶかもしれないと思うので、彼らのコーディングスタイルに従うのはイライラします。しかし、その後、それが期限を満たすための最速の方法です。 より多くの経験を持つ人にとって、どれがより効果的ですか？クリーンアップを後で保存する必要がありますか？または、変更の途中でクリーンアップしますか？ （私は慢に聞こえたくはありませんが、それは現実です。より良いコードを書くのに何年もかかるでしょう。

38 coding-style  html  clean-code 

最近、GitHubで多くのオープンソースRuby（またはその大部分がRuby）プロジェクトに遭遇しました。Rubocopなどのコード分析ツールで確認すると、多くの違反が発生します。 現在、これらの違反のほとんどには、単一引用符の代わりに二重引用符を使用することが含まれています（補間ではない場合）、レベルごとに2スペースの規則に従っていない、80文字の行長規則を超えている、または複数行のブロックを使用{し}ています。 [The] Rubyスタイルガイドでは、実際のRubyプログラマーが他の実際のRubyプログラマーが保守できるコードを作成できるように、ベストプラクティスを推奨しています。〜ソース：Rubyスタイルガイド 小さくて簡単に修正できますが、オフェンスを修正してプルリクエストを行うことで、オープンソースプロジェクトのコーディングスタイルを変更することは適切ですか？私はRailsのようないくつかのプロジェクトは、ことを認め化粧品の変更を受け入れないと、一部がRubocopが実行されたとき（Railsが例えば80,000犯罪を生成し、一度にすべての「修正」にあまりにも大きいです-に関係なく、彼らは独自の小さなセット持ってコーディングを貢献する際に従うべき規則）。結局のところ、Rubocopのようなツールと一緒にRubyスタイルガイドがあります。 人々は一貫性を高く評価しているので、このような変更を加えることは、Rubyコミュニティ全体にとって良いことです。 [Rubyスタイルガイドの著者]は、どこからともなくすべてのルールを思いついたわけではありません。それらは、主にプロのソフトウェアエンジニアとしての幅広いキャリア、Rubyコミュニティのメンバーやさまざまなメンバーからのフィードバックや提案に基づいています「Programming Ruby 1.9」や「The Ruby Programming Language」など、高く評価されているRubyプログラミングリソース。〜ソース：Rubyスタイルガイド コミュニティコーディングスタイルの規則とベストプラクティスに従っていないため、基本的に悪いプラクティスを奨励していませんか？

38 open-source  coding-style  ruby 

次のようなメソッドチェーンを使用する場合： 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 

私はPythonやJavascript（およびオブジェクト指向ではない他の言語）の出身であり、Javaの実用的な知識を向上させようとしています。 常にthis現在のインスタンス属性の先頭に追加するのは悪い習慣と見なされますか？書くほうが自然に感じます ... private String foo; public void printFoo() { System.out.println(this.foo); } ... より ... private String foo; public void printFoo() { System.out.println(foo); } ... インスタンス属性とローカル変数を区別するのに役立ちます。 もちろん、Javascriptのような言語では、よりthis多くの関数をネストできるため、常に使用する方が理にかなっています。したがって、ローカル変数はより大きなスコープから取得されます。Javaでは、私が理解している限り、このようなネストは不可能です（内部クラスを除く）。したがって、おそらく大きな問題ではありません。 いずれにせよ、私は使用したいと思いますthis。風変わりではなく、奇妙に感じますか？

37 java  coding-style