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

最近、私はプロの仕事を得て、他のプログラマーと付き合い、業界で友達を作りました。唯一のことは、私は100％独学です。それは、私のスタイルが適切に訓練されたスタイルから大きく逸脱する原因になりました。異なるのは、私のコードのテクニックと構成です。 それは私がするいくつかのことの混合物です。私はいくつかのプログラミングパラダイムをブレンドする傾向があります。機能的およびオブジェクト指向のように。私はオブジェクト指向よりも機能的な側面に傾いていますが、抽象的なエンティティとして何かがより理にかなっている場合にオブジェクト指向の使用を見ます。ゲームオブジェクトのような。次に、私は何かをするときも簡単なルートに行きます。対照的に、プロのプログラマーから見たコードは、そのために複雑な場合があるようです！私は多くのクロージャーを使用しています。そして最後に、私は最高のコメント者ではありません。コメントを読むよりコードを読むだけの方が簡単だと思います。そしてほとんどの場合、コメントがあったとしてもコードを読んでしまいます。加えて、コードを簡単に書くことができるため、非常に読みやすいと言われました。 専門的な訓練を受けたプログラマーが単体テストのようなことを続けていると聞きます。私が今まで使用したことがないものなので、それらが何であるか、またはどのように機能するかについての微妙な考えすらありません。たくさんのアンダースコア「_」は、本当に私の好みではありません。私が使用する技術のほとんどは、私から直接のもの、または私が読んだ数冊の本です。MVCについては何も知りません。backbone.jsのようなものについてはよく耳にします。アプリケーションを整理する方法だと思います。ただ私を混乱させているのは、今では自分の組織構造を作ったからです。 それは少し苦痛です。UbuntuのQuicklyのような新しいことを学ぶときは、テンプレートアプリケーションをまったく使用できません。訓練を受けた人からだとわかるコードを理解するのに苦労しています。完全なオブジェクト指向プログラミングは本当に私の口に悪い味を残しますが、それは他の誰もが厳密に使用しているもののようです。 自分のコードの見栄えに自信がなかったり、入社時に火花を散らしたり、オープンソースプロジェクトに貢献したりするのではないかと思いました。実際、私は人々が最終的に私のコードをチェックアウトするという事実をかなり恐れています。これはプログラマーが経験する普通のことなのでしょうか、それとも本当に自分のテクニックを変えるべきなのでしょうか？

36 design  javascript  coding-style  professionalism 

Cで2つの文字列を連結する関数を書きたいと仮定しましょう。それを書く方法は次のとおりです。 void concat(char s[], char t[]){ int i = 0; int j = 0; while (s[i] != '\0'){ i++; } while (t[j] != '\0'){ s[i] = t[j]; i++; j++; } s[i] = '\0'; } ただし、K＆Rの本では、特にwhileループの条件部分にできるだけ多くを含めて、異なる方法で実装しています。 void concat(char s[], char t[]){ int i, j; i = j = 0; while (s[i] …

35 programming-practices  coding-style 

私はソフトウェアエンジニアリングが初めてなので、学習演習としてチェスゲームを書きました。私の友人はそれを見て、私のコードが次のように見えることを指摘しました for (int i = 0; i < 8; i++){ for (int j = 0; j < 8; j++){ 彼は代わりにあるべきだと主張した for (int i = 0; i < CHESS_CONST; i++){ for (int j = 0; j < CHESS_CONST; j++){ 私が今考えるのが面倒ではないいくつかのより良いシンボル名で。 もちろん、私は一般的にマジックナンバーの使用を避けることを知っていますが、 この数は変更されません。 番号はコード全体で非常に多くの場所で使用されているため、名前はとにかく説明的ではありません。そして チェスプログラムのソースコードを調べている人は、8の目的を知るためにチェスについて十分に知っている必要があります。 シンボリック定数は本当に必要ありません。 では、皆さんはどう思いますか？これはやり過ぎですか、それとも慣習に沿ってシンボルを使用する必要がありますか？

34 coding-style  coding-standards 

私は上級コーダーからこの話を聞いたことがあり、自分でその一部を見てきました。無意味なコードを書いているプログラマーのインスタンスがいくつかあるようです。次のようなものが表示されます。 価値のないメソッドまたは関数呼び出し。 個別のクラスファイル、オブジェクト、またはメソッドで行われる冗長チェック。 if 常に真と評価されるステートメント。 スピンオフし、注目に値しないスレッド。 ほんの数例を挙げます。これは、プログラマーが意図的にコードを混乱させて組織に自分の価値を高めたい、または契約や外部委託の作業の場合に繰り返しビジネスをしたいからだと言われました。 私の質問は。他の誰かがこのようなコードを見ましたか？そのコードが存在した理由は何でしたか？ 誰かがこのようなコードを書いた場合、その理由を共有できますか？

34 coding-style 

私は主にパイリントを使用してソースコードをリントするPythonプログラマです。1つを除くすべての警告を削除できます：定数の名前が無効です。名前をすべて大文字に変更すると修正されますが、本当にそうすることになっていますか？私がそれを行うと、ほとんどの変数が定数であるため、コードがいように見えます（pylintによると）。

34 python  coding-style  coding-standards  conventions 

私が働いている会社は、次のような初期化関数を使用して、すべてのデータ構造を初期化しています。 //the structure typedef struct{ int a,b,c; } Foo; //the initialize function InitializeFoo(Foo* const foo){ foo->a = x; //derived here based on other data foo->b = y; //derived here based on other data foo->c = z; //derived here based on other data } //initializing the structure Foo foo; InitializeFoo(&foo); 私はこのような構造体を初期化しようとするいくつかのプッシュバックを得ました： …

33 c  coding-style  constructors  initialization 

コードレビューの後、デザインの選択について議論したところです。あなたの意見は何でしょうか。 このPreferencesクラスは、キーと値のペアのバケットです。NULL値は正当です（重要です）。特定の値がまだ保存されていない可能性があり、要求されたときに事前定義されたデフォルト値で初期化することにより、これらのケースを自動的に処理したいと考えています。 説明したソリューションでは、次のパターンを使用しました（注：これは実際のコードではなく、明らかに-説明のために単純化されています）。 public class Preferences { // null values are legal private Map<String, String> valuesFromDatabase; private static Map<String, String> defaultValues; class KeyNotFoundException extends Exception { } public String getByKey(String key) { try { return getValueByKey(key); } catch (KeyNotFoundException e) { String defaultValue = defaultValues.get(key); valuesFromDatabase.put(key, defaultvalue); return defaultValue; } …

33 java  programming-practices  coding-style  exceptions  anti-patterns 

プロジェクトで、次のようなコードを見つけました。 class SomeClass { private SomeType _someField; public SomeType SomeField { get { return _someField; } set { _someField = value; } } protected virtual void SomeMethod(/*...., */SomeType someVar) { } private void SomeAnotherMethod() { //............. SomeMethod(_someField); //............. } }; これが悪いコードであることをチームメートに納得させるにはどうすればよいですか？ これは不必要な複雑さだと思います。既にアクセスできるのに、メソッド変数としてメンバー変数を渡すのはなぜですか？これもカプセル化の違反です。 このコードに他の問題がありますか？

33 code-quality  coding-style 

たとえば、次のようなフラグメントを作成するコードを見たことがあります。 Fragment myFragment=new MyFragment(); MyFragmentではなくFragmentとして変数を宣言します。MyFragmentはFragmentの子クラスです。このコードは次のようにすべきだと思うので、このコード行を満足していません MyFragment myFragment=new MyFragment(); より具体的ですが、本当ですか？ または質問の一般化では、使用するのは悪い習慣ですか？ Parent x=new Child(); の代わりに Child x=new Child(); 前者をコンパイルエラーなしで後者に変更できるとしたら？

32 object-oriented  coding-style  refactoring  inheritance 

クラスのいくつかのメソッドで共通のデータを使用する必要がある場合、これらの2つの方法のどちらを使用するかを決めるのに苦労することがよくあります。より良い選択は何でしょうか？ このオプションでは、インスタンス変数を作成して、追加の変数を宣言する必要を回避し、メソッドパラメーターの定義を回避することもできますが、これらの変数がインスタンス化/変更される場所はそれほど明確ではありません。 public class MyClass { private int var1; MyClass(){ doSomething(); doSomethingElse(); doMoreStuff(); } private void doSomething(){ var1 = 2; } private void doSomethingElse(){ int var2 = var1 + 1; } private void doMoreStuff(){ int var3 = var1 - 1; } } または、ローカル変数をインスタンス化して引数として渡すだけですか？ public class MyClass { MyClass(){ int var1 …

32 java  coding-style 

たとえば、0、0.5、... 5のボタンのリストを表示し、0.5ごとにジャンプします。私はforループを使用してそれを行い、ボタンSTANDARD_LINEで異なる色を使用しています： var MAX=5.0; var DIFF=0.5 var STANDARD_LINE=1.5; for(var i=0;i<=MAX;i=i+DIFF){ button.text=i+''; if(i==STANDARD_LINE){ button.color='red'; } } この場合、IEEE 754では各値が正確であるため、丸めエラーはありませんが、浮動小数点の等価比較を避けるために変更する必要がある場合は苦労しています： var MAX=10; var STANDARD_LINE=3; for(var i=0;i<=MAX;i++){ button.text=i/2.0+''; if(i==STANDARD_LINE/2.0){ button.color='red'; } } 一方で、元のコードはよりシンプルで、私にとっては楽しみです。しかし、私が検討していることが1つあります。i== STANDARD_LINEはジュニアチームメイトを誤解させますか？浮動小数点数に丸め誤差がある可能性があるという事実を隠していますか？この投稿のコメントを読んだ後： https://stackoverflow.com/questions/33646148/is-hardcode-float-precise-if-it-can-be-represented-by-binary-format-in-ieee-754 一部の浮動小数点数が正確であることを知らない開発者が多いようです。私の場合、浮動小数点数の等価比較が有効であっても、避けるべきですか？または、私はこれについて考えすぎていますか？

31 javascript  coding-style  floating-point 

問題： 長い間、私はexceptionsメカニズムが本当に何をすべきかを実際には解決しないと感じているため、メカニズムについて心配しています。 クレーム：このトピックについては長い議論があり、それらのほとんどはexceptionsエラーコードの比較と返送に苦労しています。これは間違いなくここのトピックではありません。 エラーを定義しようとすると、Bjarne Stroustrup＆Herb SutterのCppCoreGuidelinesに同意します エラーは、関数が公示された目的を達成できないことを意味します クレーム：exceptionメカニズムは、エラーを処理するための言語セマンティックです。 クレーム：私には、タスクを達成しないための機能には「言い訳」がありません：機能が結果を保証できないように事前/事後条件を誤って定義したか、開発に時間を費やすために特定の例外的なケースが十分に重要ではないと考えられます解決策。IMOでは、通常のコードとエラーコードの処理の違いは（実装前に）非常に主観的なものだと考えています。 クレーム：例外を使用して、事前または事後条件が維持されていないことを示すことはexception、主にデバッグの目的で、メカニズムの別の目的です。私はexceptionsここのこの使用法をターゲットにしません。 多くの書籍、チュートリアル、およびその他のソースでは、エラー処理は非常に客観的な科学として示される傾向がexceptionsありますが、それは解決され、catchあらゆる状況から回復できる堅牢なソフトウェアが必要です。しかし、開発者としての数年間は、別のアプローチから問題を見るようになりました。 プログラマは、特定のケースがあまりにもまれに慎重に実装できないと思われる場合に例外をスローすることにより、タスクを単純化する傾向があります。この典型的なケースは次のとおりです。メモリ不足の問題、ディスクの空き容量の問題、破損したファイルの問題など。これで十分かもしれませんが、必ずしもアーキテクチャレベルから決定されるわけではありません。 プログラマは、ライブラリの例外に関するドキュメントを注意深く読んでいない傾向があり、通常、関数がスローするタイミングとタイミングを認識していません。さらに、たとえ知っていても、実際には管理していません。 プログラマーは、十分早くに例外をキャッチしない傾向があります。そして、それらをキャッチする場合、ほとんどの場合、ログに記録してさらにスローします。（最初のポイントを参照）。 これには2つの結果があります。 頻繁に発生するエラーは、開発の初期段階で検出され、デバッグされます（これは良いことです）。 まれな例外は管理されず、ユーザーのホームでシステムがクラッシュします（素敵なログメッセージが表示されます）。エラーが報告される場合もあれば、そうでない場合もあります。 それを考慮すると、IMOのエラーメカニズムの主な目的は次のとおりです。 特定のケースが管理されていないコードで可視化する。 この状況が発生した場合、問題のランタイムを関連コード（少なくとも呼び出し元）に伝えます。 回復メカニズムを提供します exceptionエラー処理メカニズムとしてのセマンティックの主な欠陥はIMOです。throwソースコードのどこにa があるかは簡単にわかりますが、宣言を見ることで特定の関数がスローできるかどうかはわかりません。これは、上で紹介したすべての問題をもたらします。 言語は、言語の他の側面（たとえば、強力なタイプの変数）の場合ほど厳密にエラーコードを適用およびチェックしません。 解決策を試す これを改善するために、非常に単純なエラー処理システムを開発しました。これは、通常のコードと同じレベルのエラー処理をエラー処理にしようと試みます。 アイデアは次のとおりです。 各（関連する）関数は、success非常に軽いオブジェクトへの参照を受け取り、場合によってはエラー状態に設定することがあります。オブジェクトは、テキスト付きのエラーが保存されるまで非常に軽いです。 提供されたオブジェクトに既にエラーが含まれている場合、関数はそのタスクをスキップすることが推奨されます。 エラーを無効にしないでください。 完全な設計では、明らかに各側面（約10ページ）を徹底的に検討し、OOPへの適用方法も検討します。 Successクラスの例： class Success { public: enum SuccessStatus { ok = 0, // All is fine error = 1, // …

31 c++  coding-style  exceptions  paradigms 

コードインデントを導入したユーザーと、導入された時期と場所を調べることに興味があります。 コードを理解することはとても重要に思えますが、普遍的ではありませんでした。ほとんどのFortranおよびBasicコードはインデントされていない（ですか？）ため、Cobolでも同じことが言えます。 連続した行折り返しのテキストとして書かれた古いLispコードを見たことさえあると確信しています。それを解析するためだけに頭の中の括弧を数える必要がありました。 では、このような大きな改善はどこから来たのでしょうか？私はその起源の言及を見たことがありません。 元の使用例とは別に、私はインデントの元の議論も探しています。

31 coding-style  history  indentation 

a KeyValuePairやa などの事前に構築された汎用構造を使用する代わりに、いつ独自のクラスにデータのキー/値型を配置する必要がありますTupleか？ たとえば、私が作成するほとんどのComboBoxには、DisplayNameとValueが含まれています。これは、新しいクラスをいつ追加し、いつKeyValuePairを使用するかを決定しようとしている種類のデータです。 私は現在iCalendar、を使用するものに取り組んでおり、選択したユーザーのデータは最終的key1=value1;key2=value2;に文字列のタイプに結合されます。最初にデータをaに入れることから始めましたKeyValuePair<string,string>が、今ではそれが代わりに独自のクラスであるのか疑問に思っています。 全体として、KeyValuePair2プロパティオブジェクトのような既存の構造/クラスを使用することを決定する際にどのガイドラインが使用されるか、また、どのような状況で他のオブジェクトを使用するかを知ることに興味があります。

31 c#  coding-style 

これはやや物議を醸すトピックであり、プログラマーと同じくらい多くの意見があると思います。しかし、そのために、ビジネス（または職場）での一般的な慣行を教えてください。 私の職場では、厳密なコーディングガイドラインがあります。その1つのセクションは、マジックストリング/マジックナンバー専用です。状態（C＃の場合）： コードでは、記号定数を定義する以外に、数値または文字列のリテラル値を使用しないでください。次のパターンを使用して、定数を定義します。 public class Whatever { public static readonly Color PapayaWhip = new Color(0xFFEFD5); public const int MaxNumberOfWheels = 18; } 例外があります：値0、1、nullはほとんど常に安全に使用できます。多くの場合、値2および-1も問題ありません。ロギングまたはトレースを目的とした文字列は、この規則から除外されます。リテラルは、意味が文脈から明らかであり、将来の変更の影響を受けない場合に許可されます。 mean = (a + b) / 2; // okay WaitMilliseconds(waitTimeInSeconds * 1000); // clear enough 理想的な状況は、次の場合にコードの可読性/保守性への影響を示す公式の研究論文です。 魔法の数字/文字列がいたるところにある 魔法の文字列/数字は、一定の宣言によって合理的に（またはさまざまな範囲で）置き換えられます-「合理的に」使用することについて私に怒鳴らないでください 魔法の文字列/数字は、過剰に置き換えられる必要があります（以下の私の例を参照） 私の同僚の1人と議論するときに科学的根拠に基づいた議論をするためにこれをしたいと思います。彼は次のような定数を宣言するようになります： private const char SemiColon = ';'; private …

31 coding-style  refactoring  coding-standards  readability  maintainability