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

私はこの質問に少し前に出くわしました、そして私はそこから材料のいくつかを引き出しています：「break n」コンストラクトの名前はありますか？ これは、二重にネストされたforループから抜け出すようにプログラムに指示する必要がある人々にとって、不必要に複雑な方法のようです。 for (i = 0; i < 10; i++) { bool broken = false; for (j = 10; j > 0; j--) { if (j == i) { broken = true; break; } } if (broken) break; } goto文は悪魔だと言うのが好きな教科書を知っています。私はそれらが好きではありませんが、これは規則の例外を正当化するのでしょうか？ nネストされたforループに対処する答えを探しています。 注：「はい」、「いいえ」、またはその中間のいずれで回答しても、完全に近い考え方の回答は歓迎されません。特に答えが「いいえ」の場合は、正当で正当な理由を提供してください（とにかくStack Exchangeの規制からそれほど遠くない）。

15 coding-style  goto 

プログラマーは作者であり、抽象的な思考や概念を表現するためのコードを書いているので、他のプログラマーは問題や誤解なく良いコードを読む必要があるので、プログラマーはより良いコードを書くためにレッスンを書くべきですか？ 概念と現実世界の問題/エンティティを抽象化することは、優れたコードを書く上で重要な部分です。また、コーディングに使用される言語の優れた習熟により、プログラマーは自分の考えをより簡単に、またはより良い方法で表現できるはずです。また、コードを改善するためにコードを記述または書き換えようとすると、関数、変数、またはデータ構造の名前を決定するのに多くの時間を費やすことができます。 これは、異なるプログラマー間の誤解の原因となることが多い、複数の意味を持つコードの記述を避けるのにも役立つと思います。コードは常にその機能を明確に表現する必要があります。

15 programming-practices  coding-style  code-quality 

EF 4.1 Code Firstチュートリアルでは、次のコードが提供されています。 public class Department { public int DepartmentId { get; set; } [Required] public string Name { get; set; } public virtual ICollection<Collaborator> Collaborators { get; set; } } 次に、流れるようなインターフェイスがより柔軟であることが説明されています。 データアノテーションは間違いなく簡単に使用できますが、はるかに柔軟性の高いプログラムによるアプローチを使用することをお勧めします。 流れるようなインターフェースの使用例を次に示します。 protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Department>().Property(dp => dp.Name).IsRequired(); modelBuilder.Entity<Manager>().HasKey(ma => ma.ManagerCode); modelBuilder.Entity<Manager>().Property(ma => ma.Name) …

15 c#  coding-style 

最近、このプログラミングのイディオムに出会いました。 const float Zero = 0.0; これは比較で使用されます： if (x > Zero) {..} これが実際よりも効率的であるか、読み取り可能または保守可能であるかを誰でも説明できますか？ if (x > 0.0) {..} 注：この定数を定義する他の理由を考えることができますが、このコンテキストでの使用について疑問に思っています。

15 coding-style  maintenance  readability  const 

Clean Codeの Bob Martinが推奨しているように、私は一般的に小さなメソッドを使用することを好みます。また、Objective-Cの内部についても十分に読んで、メッセージのディスパッチがどのように機能するかについて少なくともある程度理解しました（これについてはbbumsシリーズが特に有益です）。 時期尚早な最適化の懸念にもかかわらず、Objective-cがobjc_msgSendで実行するすべての作業が、実用的な観点から、Objective-Cプロジェクトには「多くの小さなメソッド」アプローチが不適切であるかどうかを知りたいと思います。 経験的な調査結果は特に歓迎します（多分私はいつか自分でテストをセットアップするでしょう）。大規模なObjective-Cプロジェクトを書いた人からの経験も素晴らしいでしょう。 明確化 質問の一般的な口調は意図的です。特定のアプリのパフォーマンスチューニングについては質問していません（そのため、SOではなくここで質問します）。Objective-Cの言語特性が特定の設計アプローチを妨げているかどうかについては詳しく説明しません。Appleや他の関係者（githubなど）から見たコードの多くは大きなメソッド（およびクラス）に向かう傾向があることに気付きましたが、これは言語のために忍び込んだバイアスかどうか疑問に思っています自体。もちろん、間違ったコードを読んでいた可能性があります。または、存在する場合は、傾向をもたらした技術的要因ではなく文化的要因である可能性があります。 （価値があることのために、私は現在Objective-Cを書いており、小さなメソッドを使用しています） さらなるリクエスト 与えられた両方の答えに同意します。さらにもう1つ欲しいのは、誰かが素敵な短いメソッド（および小さなクラス）を使用する（願わくば実質的な）オープンソース（またはそうでなければ見える）のObjective-Cコードベースを指し示すことです。Objective-Cには、たとえばフィットネスソースと比較するものはまだありません。

15 design  coding-style  objective-c 

開発者は、次のif/elseような1行のコードステートメントでブロックを記述します。 if (condition) // Do this one-line code else // Do this one-line code 別の方法では、すべてに中括弧を使用します。 if (condition) { // Do this one-line code } else { // Do this one-line code } 開発者は最初にオブジェクトをインスタンス化してから使用します。 HelperClass helper = new HelperClass(); helper.DoSomething(); 別の開発者は、オブジェクトを1行でインスタンス化して使用します。 new HelperClass().DoSomething(); 開発者は配列とforループを使用する方が簡単です： string[] ordinals = new string[] {'First', 'Second', …

15 project-management  productivity  coding-style 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 学生としても、テストに合格した（していない）プログラマーのコードを確認するよう求められます（Androidでフィボナッチ数のリストを作成します）。 私はコーディングスタイルに非常に厳しいのですが、誰かが使用した「ブロック」スタイルについて読んだだけです（コメントを読んでください！）。 私の立場では、この種のスタイルを使用している人を雇わないことをお勧めします。このコードは、私の会社で使用されているコーディングスタイルとはまったく逆です。 コーディングスタイルとその欠如に対処する方法を探している間、私は1つのことについて興味があります。深刻なトラブル 会社で使用されているコーディングスタイルを採用していますか？ お願い：これはコーディングスタイル全般についての議論ではなく、どちらの方がよいでしょう。誰かを雇うという決定のためのコーディングスタイルの重要性についてです！ 詳しくは： 私は決定を下す人ではなく、コードに基づいて意見を述べるだけです。その男は、ソフトスキルをチェックするものすべての私たちの頭でインタビューを渡す必要があります。彼がこれに合格した場合、彼は私たちの小さなスキルテストに合格する必要があります。私はイエスかノーと言う立場にありません。レビューでコーディングスタイルがどれほど重要かを知りたいだけです...

15 hiring  coding-standards  coding-style 

私はグーグルコーディングガイドを見ていました[ここ]、彼らは私がそれを誤解しなかった場合、using namespaceまたはを使用することをお勧めしませんnamespace::function。 これstdは同様に適用されますか？cout<<それなしでは機能しません。この本は、同じことをお勧めします。では、またはなしで使用するにはどうすれcout<<ばusing namespace std;よいstd::cout<<ですか？ 推奨される方法は何ですか？std::cout<<？ほとんどのC ++教科書using namespace std;は初心者向けに、コーディングの習慣が乏しいことを教えていますか？

15 c++  coding-style 

マジックナンバーを避けるために、リテラルに意味のある名前を付ける必要があるとよく耳にします。といった： //THIS CODE COMES FROM THE CLEAN CODE BOOK for (int j = 0; j < 34; j++) { s += (t[j] * 4) / 5; } -------------------- Change to -------------------- int realDaysPerIdealDay = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j = 0; j …

14 coding-style  code-quality  clean-code  code-reviews 

私はまだ見習いプログラマーであると考えているので、私はいつも典型的なプログラミングのための「より良い」方法を学ぼうとしています。今日、私の同僚は私のコーディングスタイルが不必要な仕事をしていると主張しており、他の人から意見を聞きたいと思っています。通常、OOP言語（通常はC ++またはPython）でクラスを設計するとき、初期化を2つの異なる部分に分けます。 class MyClass1 { public: Myclass1(type1 arg1, type2 arg2, type3 arg3); initMyClass1(); private: type1 param1; type2 param2; type3 param3; type4 anotherParam1; }; // Only the direct assignments from the input arguments are done in the constructor MyClass1::myClass1(type1 arg1, type2 arg2, type3 arg3) : param1(arg1) , param2(arg2) , param3(arg3) {} …

14 design  object-oriented  coding-style 

Java 8以降、defaultメソッドがインターフェイスに導入されました。事実上、これはのすべてのメソッドがであるとinterfaceは限らないことを意味しますabstract。 Java 9（おそらく）以降、privateメソッドは許可されます。これは、のすべてのメソッドがであるとinterfaceは限らないことを意味しますpublic abstract。 「Javaインターフェイスのメソッドは、publicアクセス修飾子を付けて、または付けずに宣言する必要がありますか？」という質問 スタックオーバーフローで/programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-mで尋ねられました そこでは、ほとんどの回答はpublic abstract使用すべきではないと主張しました。なぜなら、のメソッドはinterface以外のものではないからですpublic abstract。もはやそうではありません。 インターフェースのこれらの新しい機能をpublic abstract考慮して、Javaインターフェースメソッドの宣言でキーワードを使用する必要がありますか？ 私の特定の環境では、経験豊富なソフトウェアエンジニアがJavaを経験していない人がいて、Javaコードを時々読んでいます。public abstractキーワードを省略すると、インターフェースがこれらのキーワードを使用するためのさまざまなルールを持つようになった経緯に詳しくない人にとっては、さらなる混乱点が生じると思います。

14 java  coding-style  interfaces  coding-standards  keywords 

私は単純な暗号化の演習用にRubyコードを書いていますが、このジレンマに頻繁に遭遇しています（この演習は、知っていなければならないソリティア暗号です）。反復を排除したり、エラーの機会を最小限にしたりする簡潔で高密度のステートメントの代わりに、関数を読みやすくする記述変数とシングルステップステートメントでロジックをパディングするかどうかの問題です。 私の最新の例：私のプログラムは入力を受け取り、厳格な形式のガイドラインのために、入力を暗号化または復号化する必要があるかどうかを簡単に判断できます。単純化するには、暗号化キーとメッセージが互換性があるように変換/生成されたら、暗号化されたメッセージからキーを減算するか、暗号化されていないメッセージにキーを追加して、目的の出力を取得します（キーを暗号化として考え、メッセージ+暗号化=コード、コード-暗号化=メッセージ）。DRYの位置は、暗号化されたメッセージを暗号化されていないメッセージとは異なる方法で変換する必要があることを示しています。これは、関数内にネストされたifステートメントが必要であることを意味しますが、ロジックはしっかりしているように見えます。ただし、このコードは簡単には読み込めません。 一方、アプリケーションが暗号化または復号化を決定するときに設定されるフラグに基づいて呼び出される2つの異なる関数を作成できます。これは読みやすくなりますが、暗号化キーをメッセージに適用する（メッセージを暗号化または復号化する）高レベルの機能を複製します。 読みやすいコード、または簡潔なコードに頼るべきですか？または、この機能を取得して両方の原則を満たす別の方法を逃しましたか？プロジェクトの目的を考慮し、その目的を果たすために最善の決定を下さなければならないスケールに沿った位置ですか？ これまでのところ、読みやすいコードよりも簡潔なDRYコードを強調する傾向があります。

14 object-oriented  coding-style 

C ++でtypedefを使用すべきかどうか、またいつ使用すべきかについて少し混乱しています。読みやすさと明快さのバランスをとる行為だと思います。 typedefを使用しないコードサンプルを次に示します。 int sum(std::vector<int>::const_iterator first, std::vector<int>::const_iterator last) { static std::map<std::tuple<std::vector<int>::const_iterator, std::vector<int>::const_iterator>, int> lookup_table; std::map<std::tuple<std::vector<int>::const_iterator, std::vector<int>::const_iterator>, int>::iterator lookup_it = lookup_table.find(lookup_key); if (lookup_it != lookup_table.end()) return lookup_it->second; ... } かなりいIMO。そこで、関数内にtypedefをいくつか追加して、見栄えを良くします。 int sum(std::vector<int>::const_iterator first, std::vector<int>::const_iterator last) { typedef std::tuple<std::vector<int>::const_iterator, std::vector<int>::const_iterator> Lookup_key; typedef std::map<Lookup_key, int> Lookup_table; static Lookup_table lookup_table; Lookup_table::iterator lookup_it = lookup_table.find(lookup_key); …

14 c++  coding-style 

私にとって、定型的なコードは明らかに悪いです。しかし、ボイラープレートを減らすために抵抗を示す開発者に会いました。私は、私が長年にわたってそれに対して開発した嫌悪感を超えて、すぐに形成された、よく考えられた議論を持っていなかったことに気付きました。 定型文を少なくするという説得力のある議論を形成できるように、いくつかの反論は何ですか？言い換えれば、ボイラープレートを支持する議論（もしあれば）は何ですか？ （私は一般的に定型語が意味すると思うものを意味しますが、良い例はJavaのゲッターとセッターです。）

14 programming-languages  programming-practices  coding-style  refactoring 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 私の考え方では、forループを使用して、既知の範囲または決定可能な範囲を反復処理します。 String[] names = //something; for ( int i = 0; i < names.length; i++ ) { //do stuff } これは（iの範囲を除いて）と同等です： String[] names = //something; int i = 0; while (i < names.length ) { // do stuff i++; } 言い換えれば、forループは、一般的に使用されるwhile構造の単純な（非常に有用な）構文糖です。 しかし、私for(;;)は機能的にと同等であるウェブ上の多くの構造を見ていますwhile(true) これの理由は何ですか？無限forループが無限whileループよりも優先されるのはなぜですか？ // whileループをまったく使用しないjavaテキストも見ました！次のような巨大な構成要素につながる： String input = …

14 language-agnostic  coding-style