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

「同じメソッドに複数のreturnステートメントを入れないでください」と言うプログラマーとよく話します。理由を教えてもらうと、「コーディング標準がそう言っている」または「わかりにくい」だけです。単一のreturnステートメントでソリューションを表示すると、コードが見苦しくなります。例えば： if (condition) return 42; else return 97; 「これは見苦しいです。ローカル変数を使用する必要があります！」 int result; if (condition) result = 42; else result = 97; return result; この50％のコードの肥大化により、プログラムが理解しやすくなりますか？個人的には、簡単に防ぐことができた別の変数によって状態空間が増加したため、私はそれが難しいと感じています。 もちろん、通常は次のように書きます。 return (condition) ? 42 : 97; しかし、多くのプログラマーは条件演算子を避け、長い形式を好みます。 この「一回限りの帰り」という概念はどこから来たのでしょうか？このコンベンションが生まれた歴史的な理由はありますか？

1055 coding-style  coding-standards  history  control-structures 

私はよくこの種の関数を両方の形式で記述しましたが、ある形式が別の形式よりも好まれるのか、そしてその理由は疑問でした。 public void SomeFunction(bool someCondition) { if (someCondition) { // Do Something } } または public void SomeFunction(bool someCondition) { if (!someCondition) return; // Do Something } それはコーディング中の私の脳の働きであるため、私は通常最初のものでコーディングしますが、エラー処理をすぐに処理し、読みやすいので2番目のものを好むと思います

304 coding-style  conditions  control-structures 

中かっこは独自の行にあるべきですか？あなたはそれについてどう思いますか？ if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } またはそれがあるべき if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } あるいは if (you.hasAnswer()) you.postAnswer(); else you.doSomething(); 建設的にしてください！理由を説明し、経験を共有し、事実と参考文献でバックアップします。

273 coding-style  code-formatting 

私の上司は、下手なプログラマーがループ内で使用している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 

私には知り合いがいて、私よりもベテランの開発者です。私たちはプログラミングの実践について話していましたが、「if」ステートメントに関する彼のアプローチには驚かされました。彼は、私がかなり奇妙だと思うifステートメントに関するいくつかの慣行を主張しています。 まず、ifステートメントの後にelseステートメントを続ける必要があります。挿入するものがあるかどうかは関係ありません。次のようなコードになります。 if(condition) { doStuff(); return whatever; } else { } 第二に、偽よりも真の値をテストする方が良いです。つまり、「！doorOpened」変数の代わりに「doorClosed」変数をテストする方がよいということです。 彼の議論は、コードが何をしているのかを明確にするということです。 これら2つのルールを組み合わせることで、条件が満たされていないときに何かを実行したい場合、この種のコードを書くようになる可能性があるため、かなり混乱しています。 if(condition) { } else { doStuff(); return whatever; } これについての私の考えは、それは実際には非常にいことである、および/または品質改善があったとしてもごくわずかであるということです。しかし、私は後輩として、本能を疑う傾向があります。 だから私の質問は次のとおりです。それは良い/悪い/「問題ではない」プラクティスですか？それは一般的な習慣ですか？

169 coding-style  conditions 

私は大規模なプロジェクトを実際に書いていません。私は巨大なデータベースを維持したり、何百万行ものコードを扱ったりしていません。 私のコードは、主に「スクリプト」タイプのもの-数学関数をテストするためのもの、または何かをシミュレートするためのもの-「科学プログラミング」です。ここまでに取り組んだ最長のプログラムは数百行のコードであり、私が取り組んでいるプログラムのほとんどは約150行です。 私のコードもがらくたです。先日私が書いたファイルを見つけようとしていたので、これに気づきましたが、おそらく私は上書きしており、バージョン管理を使用していないことを知っています。これはおそらく私の愚かさに多くの人が苦しんでいます。 私のコードのスタイルは複雑で、何かを行う別の方法を記した古いコメントや、コピーされたコード行で満たされています。変数名は常に非常にわかりやすく説明的に始まりますが、たとえば、誰かがテストしたい新しいものを追加または変更すると、コードが上にオーバーレイされて上書きされます。このことをすぐにテストする必要があると思うので、私は安っぽい変数名を使用し始め、ファイルがポットに行くフレームワークを持っています。 私が現在取り組んでいるプロジェクトでは、私はこれらすべてが私に大きな意味で噛み付いてくる段階にあります。しかし、問題は（バージョン管理を使用し、新しい反復ごとに新しいファイルを作成し、そのすべてをどこかにテキストファイルに記録することを除いて、状況を劇的に改善する可能性があります）私の実際のコーディングスタイル。 より小さなコードを書くために単体テストは必要ですか？OOPはどうですか？大規模なプロジェクトで作業するのではなく、「科学的プログラミング」を行うときに、適切でクリーンなコードを迅速に記述するのにどのようなアプローチが適していますか？ 多くの場合、プログラミング自体はそれほど複雑ではないため、これらの質問をします。私がプログラミングでテストまたは研究しているのは、数学または科学に関するものです。たとえば、2つの変数と関数がおそらくそれを処理できる場合、クラスは必要ですか？（これらは一般に、プログラムの速度が速いほうが望ましい状況であると考えてください-シミュレーションの25,000,000以上のタイムステップを実行しているとき、それを望んでいます。） おそらくこれは広すぎるので、もしそうなら、私は謝罪しますが、プログラミングの本を見ると、しばしばより大きなプロジェクトで対処されているようです。私のコードはOOPを必要とせず、すでにかなり短いので、「ああ、でもそうすればファイルは1000行減ります！」これらの小さくて高速なプロジェクトで「やり直す」方法ときれいにプログラムする方法を知りたいです。 私はもっ​​と具体的な詳細を提供したいのですが、アドバイスがより一般的であればあるほど、役に立つと思います。Python 3でプログラミングしています。 誰かが重複を提案しました。標準のプログラミング標準を完全に無視することについては話していないことを明確にしましょう。明らかに、これらの標準が存在する理由があります。しかし、一方で、いくつかの標準的なことを実行できたときにOOPと呼ばれるコードを書くことは本当に意味がありますか？プログラム？ 例外があります。さらに、科学的なプログラミングには、単なる標準を超えた標準がおそらくあります。私もそれらについて尋ねています。これは、科学的なコードを書くときに通常のコーディング標準を無視すべきかどうかではなく、きれいな科学的なコードを書くことです！ 更新 「まったく1週間後ではない」種類の更新プログラムを追加すると思いました。あなたのアドバイスはすべてとても役に立ちました。現在、バージョン管理を使用しています-git、グラフィカルインターフェイス用のgit kraken。非常に使いやすく、ファイルを大幅にクリーンアップしました。古いファイルを残したり、「念のため」に古いバージョンのコードをコメントアウトしたりする必要はもうありません。 また、pylintをインストールし、すべてのコードで実行しました。最初に1つのファイルが負のスコアを獲得しました。それがどのように可能だったのかさえ私には分かりません。私のメインファイルは、〜1.83 / 10のスコアから始まり、〜9.1 / 10になりました。すべてのコードは現在、標準にかなり準拠しています。また、自分の目で行った変数名を更新しました。 特に、私はこのサイトで最近の質問をして、私の主な機能の1つをリファクタリングしました。そして今ではずっときれいで短くなっています。サイズと何が起こっているかを把握するのがはるかに簡単です。 次のステップは、ある種の「単体テスト」を実装することです。つまり、メインファイルで実行できるファイルで、アサートステートメントとtry / exceptsを使用して、その中のすべての関数を調べます。これはおそらく最善の方法ではなく、多くの重複したコードになります。しかし、私は読み続けて、それをより良くする方法を見つけようとします。 また、すでに作成したドキュメントを大幅に更新し、Excelスプレッドシート、ドキュメント、関連するペーパーなどの補足ファイルをgithubリポジトリに追加しました。それは今や本当のプログラミングプロジェクトのように見えます。 だから...私はこれがすべてだと思います：ありがとう。

169 python  coding-style  clean-code  python-3.x 

これはささいなことではありませんが、このようなコードをコーディングする必要があるたびに、繰り返しが気になりますが、どのソリューションも悪くないかどうかはわかりません。 if(FileExists(file)) { contents = OpenFile(file); // <-- prevents inclusion in if if(SomeTest(contents)) { DoSomething(contents); } else { DefaultAction(); } } else { DefaultAction(); } この種のロジックには名前がありますか？ 私も少しOCDですか？ 好奇心のためだけに、私は邪悪なコードの提案を受け入れています...

161 coding-style  conditions 

私は今日、プログラミングの議論に参加しました。そこでは、循環参照（モジュール、クラスなど）が一般的に悪いと公理的に仮定したステートメントをいくつか作成しました。ピッチで問題が解決したら、同僚は「循環参照の何が問題になっていますか？」と尋ねました。 これには強い気持ちがありますが、簡潔かつ具体的に言葉で表現するのは難しいです。私が思いつくかもしれない説明は、公理と見なされる他の項目に依存する傾向があります（「単独では使用できないため、テストできません」、「参加オブジェクトの状態が変化するときの不明/未定義の動作」など） ）、しかし、私は循環参照が悪い理由の簡潔な理由を聞きたいです。それは私の脳が持っている種類の信仰の飛躍をとらない、何年にもわたってそれらを理解し、修正し、さまざまなコードを拡張します。 編集：二重にリンクされたリストや親へのポインターのような同種の循環参照については尋ねていません。この質問は、libAがlibAをコールバックするlibBを呼び出すなど、「より大きいスコープ」の循環参照について本当に質問しています。必要に応じて、「lib」を「module」に置き換えます。これまでのすべての答えに感謝します！

160 code-quality  coding-style 

これは、現在作業しているコードベースに大きな不満を感じています。変数名の多くは短く、説明的ではありません。私はプロジェクトに残った唯一の開発者であり、それらのほとんどが何をするかについてのドキュメントがないため、それらが表すものを追跡するために余分な時間を費やす必要があります。 たとえば、光学面の定義を更新するコードを読んでいた。開始時に設定された変数は次のとおりです。 double dR, dCV, dK, dDin, dDout, dRin, dRout dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1)); dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1)); ... and so on たぶんそれは私だけかもしれませんが、それが何を表しているのかを本質的に教えてくれなかったので、コードをさらに理解するのが難しくなりました。私が知っていたのは、それがどこか特定のテーブルから特定の行を解析する変数であることだけでした。いくつかの検索の後、私はそれらが何を意味するかを見つけました： dR = radius dCV = curvature dK = conic constant dDin = inner aperture dDout = outer aperture dRin = inner radius dRout = outer radius 本質的にそこにあるものに名前を変更しました。それはいくつかの線を長くしますが、私はそれが公正なトレードオフだと感じています。ただし、この種の命名スキームは、多くのコードで使用されています。古いシステムで作業して学んだ開発者の成果物なのか、それともより深い理由があるのか​​はわかりません。このように変数に名前を付ける正当な理由はありますか、それとも変数に出会ったときにそれらをよりわかりやすい名前に更新することは正当ですか？

140 coding-style  language-agnostic  naming 

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

139 coding-style  readability 

PEP-8 https://www.python.org/dev/peps/pep-0008/#package-and-module-namesのこの部分を見ました これがモジュール/クラス/パッケージのファイル名を参照しているかどうかはわかりません。 それぞれの例が1つある場合、ファイル名はすべて小文字にし、必要に応じてアンダースコアを使用する必要がありますか？または、他の何か？

137 python  coding-style  naming-standards 

私はバベルES6でコーディングしている上級フロントエンド開発者です。アプリの一部はAPI呼び出しを行い、API呼び出しから返されるデータモデルに基づいて、特定のフォームに入力する必要があります。 これらのフォームは二重リンクリストに格納されます（バックエンドがデータの一部が無効であると言った場合、ユーザーを混乱させた1ページにすばやく戻し、ターゲットを元に戻すことができます。リスト。） とにかく、ページを追加するために使用される関数の束があり、私はあまりにも賢いのだろうかと思っています。これは基本的な概要にすぎません-実際のアルゴリズムは非常に複雑で、さまざまなページやページタイプがありますが、例を挙げて説明します。 これが、初心者のプログラマーが処理する方法です。 export const addPages = (apiData) => { let pagesList = new PagesList(); if(apiData.pages.foo){ pagesList.add('foo', apiData.pages.foo){ } if (apiData.pages.arrayOfBars){ let bars = apiData.pages.arrayOfBars; bars.forEach((bar) => { pagesList.add(bar.name, bar.data); }) } if (apiData.pages.customBazes) { let bazes = apiData.pages.customBazes; bazes.forEach((baz) => { pagesList.add(customBazParser(baz)); }) } return pagesList; } さて、よりテストしやすくするために、これらのifステートメントをすべて取り、それらを分離し、スタンドアロンの機能にした後、それらをマップします。 …

133 coding-style  functional-programming  teamwork  senior-developer  leadership 

私自身、何かを2回以上行う必要がある場合、関数を書くのを待つことができません。しかし、2回しか表示されないものに関しては、少し注意が必要です。 3行以上を必要とするコードの場合、関数を作成します。しかし、次のようなものに直面するとき： print "Hi, Tom" print "Hi, Mary" 私は書くのをためらっています： def greeting(name): print "Hi, " + name greeting('Tom') greeting('Mary') 2番目のものは多すぎるようですね。 しかし、私たちが持っている場合： for name in vip_list: print name for name in guest_list: print name そして、代替手段は次のとおりです。 def print_name(name_list): for name in name_list: print name print_name(vip_list) print_name(guest_list) 物事はトリッキーになりますか？今決めるのは難しい。 これについてあなたはどう思いますか？

131 python  coding-style 

これは少し面倒ですがId、次のように使用する人もいます。 private int userId; public int getUserId(); および他の使用： private int userID; public int getUserID(); これらの1つは他よりも良い名前ですか？どうして？大規模なプロジェクトでは、これが非常に一貫性のない形で行われるのを見てきました。私がほとんどの人が慣れ親しんでいる標準を設定する場合はどうなりますか？従来の標準はどれですか？

126 coding-style  naming  variables 

なぜ私たちの多くが同じ変数名を使用してこの同じパターンを繰り返すのかを考えたことはありますか？ for (int i = 0; i < foo; i++) { // ... } 私が今まで見てきたほとんどのコードはi、繰り返し変数としてj、kなどを使用しているようです。 私はどこかからそれを拾ったと思うが、なぜこれがソフトウェア開発でそれほど普及しているのだろうかと思う。それは私たち全員がCから拾ったものなのでしょうか、それともそのようなものですか？ 頭の後ろでしばらくかゆみがありました。

126 programming-practices  coding-style  coding-standards