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

これらの2つのケースの間で一般的に受け入れられている方法は次のとおりです。 function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); } または function insertIntoDatabase(long accountId, long thingId, double someValue) { database.insertMethod(accountId, thingId, someValue); } 言い換えれば、一般的にオブジェクト全体を渡すか、必要なフィールドだけを渡す方が良いでしょうか？

31 design-patterns  object-oriented  programming-practices  coding-standards  encapsulation 

これはやや物議を醸すトピックであり、プログラマーと同じくらい多くの意見があると思います。しかし、そのために、ビジネス（または職場）での一般的な慣行を教えてください。 私の職場では、厳密なコーディングガイドラインがあります。その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 

SunのJavaコードの規則では、演算子の前に改行を配置することが提案されていますが、他の多くのガイドラインは改行に同意しません。明らかな長所と短所はないので、これらのスタイルの1つを別のスタイルよりも使用する利点はありますか？ String longVarName = a + b + c + d + e + f; 対 String longVarName = a + b + c + d + e + f;

29 java  coding-standards  coding-style 

最近、GitHubでPythonライブラリに出会いました。ライブラリは素晴らしいですが、関数名に1つの明白なタイプミスが含まれています。dummy_fuction()それがあるべきときにそれを呼び出しましょうdummy_function()。この関数は間違いなく「インザワイルド」であり、組み込みシステムで使用される可能性が最も高くなります。 最初に思い浮かぶのは、正しい名前の関数の2番目のバージョンを追加し、次のリリースの最初のバージョンに非推奨の警告を追加することです。 3つの質問： 上記のアプローチは、意図しない結果をもたらす可能性がありますか？ この種の問題に対する標準的なアプローチはありますか？ 非推奨の警告はいつまで残しておくべきですか？

28 python  version-control  coding-standards  deprecation 

質問： 構文classおよびid値の実用的な考慮事項は何ですか？ たとえば、このブログ投稿で説明されているように、セマンティクス、つまり使用されている実際の単語については聞いていないことに注意してください。命名規則のその側にはすでに多くのリソースがあり、実際には、さまざまな構文上のビットに関する実用的な情報の検索をあいまいにしています：大文字小文字の区別、インターパンクションの使用（特にダッシュ）、使用または回避する特定の文字など- 私がこの質問をしている理由を要約すると： 命名制限にIDとクラスが自然に任意の規則につながりません 命名規則のセマンティック側の豊富なリソースは、構文上の考慮事項の検索をあいまいにします これに関する信頼できる情報源が見つかりませんでした このトピックについては、SEプログラマーに関する質問はまだありませんでした:) 私が使用を検討した慣例のいくつか： UpperCamelCase、主にサーバー側のコーディングからのクロスオーバーの習慣として lowerCamelCase、JavaScript命名規則との一貫性のため css-style-classes、これはcssプロパティの命名と一致しています（ただし、Ctrl + Shift + ArrowKeyでテキストを選択すると迷惑になる場合があります） with_under_scores、私は個人的にあまり使用されていません alllowercase、覚えやすいが、長い名前では読みにくい UPPERCASEFTW、仲間のプログラマを困らせる素晴らしい方法として（おそらく読みやすさのためにオプション4と組み合わせる） そしておそらく、私はいくつかの重要なオプションや組み合わせも省略しました。命名規則にはどのような考慮事項があり、どの規則につながるのでしょうか？

28 coding-style  naming  html  coding-standards  css 

キーワードを大文字にしてSQLを作成する開発者が多いようです。 SELECT column FROM table INNER JOIN table ON condition WHERE condition GROUP BY clause HAVING condition なぜ人々はこのアプローチに固執するのだろうか？明らかに、これは長い間確立された慣習ですが、大文字を必要とするRDBMSに出会ったことはありません。 個人的には、キーワードが小文字で正確に記述されているのは、クエリの間違った部分に注意を喚起するキーワードを見つけるためです。 それでも、十分な人がこの慣習を使用しているので、何かが足りないと思うので、この質問をします。

28 sql  history  coding-standards 

Lispコミュニティが関数の最後にすべての括弧を蓄積することを好む理由： (defn defer-expensive [cheap expensive] (if-let [good-enough (force cheap)] good-enough (force expensive))) CやJavaのような規則を採用しないのはなぜですか？ わかりました、Lispはそれらの言語よりはるかに古いですが、私は現代のLispersについて話しています。 (defn defer-expensive [cheap expensive] (if-let [good-enough (force cheap)] good-enough (force expensive) ) ) 注：コードスニペットは、「The Joy of Clojure」という本からのものです。

26 lisp  clojure  coding-standards 

既存のサードパーティ製ソフトウェアの拡張機能を作成しようとしていたため、そのデータベースは恐ろしく非正規化されていたため、これを考えていました。既存のテーブルを使用して、多数の新しいフィールドを追加する必要がありました。 デザインスタイル（1つの大きなテーブルにあるほとんどすべてのプロパティで構成される）で新しいテーブルを作成するか、新しいテーブルセットを一緒に作成し、トリガーなどの特別なものを使用して、新しいテーブルと古いテーブル。 結局、既存の貧弱なデザインスタイルを使用するという最初のオプションに行き着きましたが、この質問が残されました：既存の悪い慣行に行くのか、既存のコードにうまく合わない良い慣行を実装するのが良いのでしょうか？どちらかを選択する必要がある状況はありますか？ 注：これまでの多くの答えは、悪いコードをゆっくりとリファクタリングすることに関係していますが、私はそれをすることができません。コードは私たちのものではなく、ベンダーによって頻繁に更新されます。私はそれの上にのみ構築できます。

25 code-quality  coding-standards  bad-code 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 C＃のプライベート変数で最も一般的に受け入れられている命名規則のベストプラクティスは何ですか？ private int myInteger; private int MyInteger; private int mMyInteger; private int _myInteger; private int _MyInteger; 神秘的な他のオプション どちらを使用しますか？（私の会社はC＃にかなり慣れていないので、コーディング業界の標準に入るために最も「業界で受け入れられている」方法を選びたいと思います。）

25 coding-standards  variables  naming 

ちょっと興味があるんだけど。Linus Torvaldsからこれを読んだので、私が今までに持っていたほとんどはforループ内のforループでした。 タブは8文字であるため、インデントも8文字です。インデント4（または2！）の文字を深くしようとする異端運動があります。これは、PIの値を3に定義しようとすることに似ています。 理論的根拠：インデントの背後にある全体的な考え方は、制御ブロックの開始位置と終了位置を明確に定義することです。特に、20時間連続して画面を見ていると、大きなインデントがある場合にインデントがどのように機能するかを簡単に確認できます。 現在、一部の人々は、8文字のインデントがあると、コードが右に移動しすぎて、80文字の端末画面で読みにくくなると主張します。 その答えは、3レベル以上のインデントが必要な場合、とにかくねじ込まれてしまい、プログラムを修正する必要があるということです。 https://www.kernel.org/doc/Documentation/CodingStyle 私は、ループの3番目の層に行くことは受け入れられない慣行であり、コードを再構築すると考えました（主にQt）。 Linusは冗談を言っていましたか？ 言語やアプリケーションに依存しますか？ 3レベル以上のループが絶対に必要なものはありますか？

23 coding-style  coding-standards  loops  indentation 

Cyclomatic Complexityを削減するためにこの方法をどのように実行するかわからない。ソナーは13を報告しますが、10が予想されます。しかし、この方法をそのままにしておいても、ソナーのルールに従う方法に挑戦するだけでは何の害もありません。どんな考えでも大歓迎です。 public static long parseTimeValue(String sValue) { if (sValue == null) { return 0; } try { long millis; if (sValue.endsWith("S")) { millis = new ExtractSecond(sValue).invoke(); } else if (sValue.endsWith("ms")) { millis = new ExtractMillisecond(sValue).invoke(); } else if (sValue.endsWith("s")) { millis = new ExtractInSecond(sValue).invoke(); } else if (sValue.endsWith("m")) { …

23 java  code-quality  refactoring  coding-standards  cyclomatic-complexity 

Xを実行する必要があるかどうかをチェックし、必要に応じてXを実行するメソッドに名前を付ける良い方法は何ですか？ たとえば、新しいユーザーがログインした場合にユーザーリストを更新するメソッドに名前を付ける方法は？UpdateListIfNeeded長すぎるように見えますが、単純なUpdateListことは、毎回高価で不必要な操作が行われることを意味します。EnsureListUpdatedバリアントでもあります。 C＃には、Xが可能かどうかを確認して実行するbool TryXXX(args, out result)パターン（たとえばint.TryParse(str, out num)）がありますが、それは微妙に異なります。

23 language-agnostic  naming  coding-standards 

ネストされた関数（PythonやDなど）をサポートする言語で複雑なアルゴリズムを扱う場合、私はしばしば（アルゴリズムが複雑なため）巨大な関数を記述しますが、ネストされた関数を使用して複雑なコードを構成することでこれを緩和します。ネストされた関数を使用して内部的に適切に構造化されていても、巨大な（100行以上の）関数は依然として悪と見なされますか？ 編集：PythonまたはDに精通していない人のために、これらの言語のネストされた関数は、外部関数スコープへのアクセスも許可します。Dでは、このアクセスにより、外部スコープ内の変数の突然変異が許可されます。Pythonでは、読み取りのみが許可されます。Dでは、宣言することにより、ネストされた関数の外部スコープへのアクセスを明示的に無効にできますstatic。

23 coding-style  coding-standards  readability  cowboy-coding 

ロックされています。この質問に対するコメントは無効になっていますが、新しい回答やその他の相互作用はまだ受け付けています。詳細をご覧ください。 検索しましたが、探しているものが見つかりませんでした。この質問が既に質問されている場合は、お気軽にリンクしてください。 今月初めにこの投稿が行われました： http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/ 基本的には、コメントを書かないと悪いプログラマーになります。私の意見では、コードは記述的であり、コードが自己記述的でない場合を除き、ほとんどコメントを必要としないはずです。 与えられた例では // Get the extension off the image filename $pieces = explode('.', $image_name); $extension = array_pop($pieces); 著者は、このコードにはコメントを付けるべきだと述べました。私の個人的な意見では、コードは記述的な関数呼び出しである必要があります。 $extension = GetFileExtension($image_filename); しかし、コメントでは誰かが実際にその提案をしました： http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/comment-page-2/#comment-357130 著者は、コメンターは「それらの人々の1人」、すなわち、悪いプログラマーであると答えました。 自己記述型コードとコメント型コードについて、他の誰もが見ていることは何ですか？

22 coding-standards  comments 

通常、コーディング標準について話すとき、プログラム自体のコードを参照しますが、単体テストについてはどうですか？単体テストに固有の特定のコーディング標準ガイドラインはありますか？彼らは何ですか？

22 coding-standards  unit-testing