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

私はC＃のAvSolコーディングガイドラインに目を通し、ほぼすべてに同意しましたが、特定のルールについて他の人がどう考えているかを知りたいと思います。 AV1500 メソッドは7つのステートメントを超えてはなりません。7つを超えるステートメントを必要とするメソッドは、処理が多すぎるか、責任が多すぎます。また、人間の心が正確なステートメントを分析して、コードが何をしているかを理解する必要があります。わかりやすい名前で、複数の小さくて焦点を絞った方法に分けてください。 あなたのほとんどはこのルールに従っていますか？読みやすさを大幅に向上させることは別として、新しいメソッドを作成すること（コードはまだDRYです）から節約できることはほとんどありませんか？そして、あなたの番号はまだ7と低いですか？私はもっ​​と10に向かう傾向があるでしょう。 私はあちこちでこの規則に違反していると言っているわけではありません。反対に、私の方法は95％小さくて集中していますが、この規則に違反してはいけないと言って本当に衝撃を受けました。 私は本当に誰もがこの規則に違反しないと思うことを知りたいだけです（コーディング標準の「1」です-これを絶対にしないでください）。しかし、そうでないコードベースを見つけるのに苦労すると思います。

78 c#  coding-standards  maintainability 

次のようなコーディング標準に取り組む必要がありましたか？ 生産性が大幅に低下しましたか？ 元々は正当な理由で含まれていましたが、元の懸念が無関係になってからずっと保持されていましたか？ リストに載っていたので、それらをすべて覚えることは不可能でしたか？ 著者は、優れたコーディングの実践を奨励するのではなく、単に彼らのマークを残そうとしていると思わせましたか？ なぜ含まれているのか分かりませんか？ もしそうなら、あなたの最も好きではないルールとその理由は何ですか？ ここにいくつかの例

77 coding-standards  coding-style 

バージョン管理システムにより、コードのいたるところに「変更ログ」を貼る必要がなくなるという印象を受けました。私は頻繁に変更ログの継続的な使用を見てきました。これには、ファイルへの変更のためにブロックされた大きなセクションを含むストアドプロシージャの開始時の大きな長いブロックが含まれます。 // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 そして： // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> 私に説明されたように、この理由は、VCSログをふるいにかけるのに時間がかかりすぎて、誰が何をなぜ変更したかを見つけようとしている間、コードファイル自体に関連する上部または近くにそれを持っているからです誰が何をいつ変更したかを簡単に確認できます。私はその点を見ていますが、冗長であり、「VCSを適切に使用する方法が本当にわからないので、そのようなことは一切気にしません。 どう思いますか？コメントとログの両方を使用していますか？ただのログ？John Smithが1週間前にXYZをチェックするようにメソッドを変更したコードブロックの上に表示されると、Diffツールでログを検索してコードファイルを比較する代わりに、コーディングが簡単になりますか？ 編集：SVNを使用しますが、基本的にはリポジトリとしてのみ。ブランチ、マージ、ログ+ストレージ以外はありません。

75 version-control  coding-standards  maintenance 

私は、ロバート・マーティンによる「クリーン・コード」を読んで、できればより良いプログラマーになることを望んでいます。これまでのところ、どれも本当に画期的なものではありませんでしたが、アプリケーションの設計とコードの記述方法について、私は違った考え方をしました。 本の一部には、同意しないだけでなく、特にインターフェースの命名規則に関して、私には意味がありません。これは、本から直接取ったテキストです。混乱を招くと思われるこの側面を太字で示し、説明を希望します。 私はインターフェースを装飾しないままにしておきたい。前のIは、今日のレガシーワッドで非常に一般的であるが、せいぜい気を散らすものであり、最悪の場合には情報が多すぎる。ユーザーにインターフェースを渡していることをユーザーに知らせたくない。 おそらく、私が学生だからか、プロやチームベースのプログラミングを一度もしたことがないからかもしれませんが、それがインターフェースであることをユーザーに知ってもらいたいからでしょう。 インターフェイスの実装とクラスの拡張には大きな違いがあります。 それで、私の質問は、「コードの一部がインターフェースを期待しているという事実を隠す必要があるのか​​？」に要約されます。 編集 回答に応じて： タイプがインターフェースである場合、またはクラスがあなたのビジネスであり、コードを使用している誰かのビジネスではない場合。したがって、このサードパーティのコードでコードの詳細を漏らさないでください。 特定の型がインターフェイスであるか、サードパーティのコードのクラスであるかの詳細を「漏洩」しないのはなぜですか？サードパーティの開発者がコードを使用して、インターフェイスを実装するのか、クラスを拡張するのかを知ることは重要ではありませんか？違いは、私が自分の頭に浮かぶほど重要ではありませんか？

73 naming  interfaces  coding-standards 

あなたがXXXコメントで見るとき、人々は一般に何を意味します。時折、次のようなコメントが表示されます。 # XXX - This widget really should frobulate the whatsit もちろん、コメントの意味はわかりますが、XXXは一般的にどういう意味ですか？「これはハックです」と言っているのでしょうか、それとも「おそらくこれを後で再検討する必要がある」でしょうか。それとも、まったく別のことを言っていますか？

72 comments  coding-standards 

大規模なC＃プロジェクトの既存のコーディング標準には、すべての型名を完全修飾するというルールが含まれており、「using」ディレクティブの使用を禁止しています。だから、おなじみではなく： using System.Collections.Generic; .... other stuff .... List<string> myList = new List<string>(); （var禁止されていることはおそらく驚くことではありません。） 私は最終的に： System.Collections.Generic.List<string> myList = new System.Collections.Generic.List<string>(); それはタイピングの134％の増加であり、その増加のどれも有用な情報を提供しません。私の見解では、増加の100％は実際に理解を妨げるノイズ（混乱）です。 30年以上のプログラミングの中で、私はそのような標準が一度か二度提案されたのを見たことがありますが、実装されたことはありません。その背後にある理論的根拠は私を逃れます。標準を課している人は愚かではなく、私は彼が悪意があるとは思わない。私が何かを逃していない限り、それは他の唯一の選択肢として見当違いのままになります。 そのような標準が課されていることを聞いたことがありますか？もしそうなら、その背後にある理由は何でしたか？usingこの禁止を取り除くようにこの人に説得するかもしれない「それは愚かだ」または「他の誰もが採用している」以外の議論を考えることができますか？ 推論 この禁止の理由は次のとおりです。 完全に修飾された型を取得するには、名前の上にマウスを移動するのは面倒です。常に完全修飾型を常に表示することをお勧めします。 電子メールで送信されたコードスニペットには完全修飾名がないため、理解が難しい場合があります。 Visual Studioの外部（Notepad ++など）でコードを表示または編集する場合、完全修飾型名を取得することはできません。 私の主張は、3つすべてのケースがまれであり、少数のまれなケースに対応するためだけに、誰もが混乱して理解しにくいコードの代価を支払うようにすることは見当違いだということです。 潜在的な名前空間の競合の問題は、私が主な関心事であると予想していましたが、言及さえされていませんでした。名前空間があるためMyCompany.MyProject.Core、これは特に驚くべきことです。これは特に悪い考えです。何かを命名しSystemたりCore、C＃で命名することは、狂気への素早い道であることをずっと前に知りました。 他の人が指摘したように、名前空間の競合は、リファクタリング、名前空間のエイリアス、または部分的な修飾によって簡単に処理されます。

71 c#  coding-standards 

新しい仕事で、次のようなコードのコードレビューでフラグを立てられました。 PowerManager::PowerManager(IMsgSender* msgSender) : msgSender_(msgSender) { } void PowerManager::SignalShutdown() { msgSender_->sendMsg("shutdown()"); } 最後のメソッドは次のように読むべきだと言われています： void PowerManager::SignalShutdown() { if (msgSender_) { msgSender_->sendMsg("shutdown()"); } } つまり、変数がプライベートデータメンバーであっても、変数をガードする必要があります。この「知恵」についてどのように感じているかを説明するためにexp辞を使うのを抑えるのは難しいです。説明を求めると、ある年のジュニアプログラマーがクラスがどのように機能するかについて混乱し、必要のないメンバーを誤って削除した（そしてその後に設定する）ことについてのホラーストーリーを大量に受け取ります、どうやら）、そして製品リリース直後に現場で物事が爆発しました。すべてをチェックする方が良いという「難しい方法を学び、信頼してください」。NULLmsgSender_NULLNULL 私にとって、これは貨物カルトのプログラミングのように感じます。いくつかの善意の同僚は、私が「それを得る」のを助け、これが私がより堅牢なコードを書くのにどのように役立つかを真剣に助けようとしていますが、...私は彼らがそれを手に入れていないように感じるのを助けることができません。 コーディング標準では、関数内で間接参照されているすべてのポインターをNULL最初にチェックすることを要求するのは妥当ですか？プライベートデータメンバーであっても？（注：コンテキストを提供するために、航空交通管制システムやその他の「障害と同等の人々が死ぬ」製品ではなく、家電製品を製造しています。） 編集：上記の例では、msgSender_共同編集者はオプションではありません。これまでNULLに発生した場合は、バグを示しています。コンストラクターに渡される唯一の理由はPowerManager、モックIMsgSenderサブクラスでテストできることです。 要約：この質問には本当に素晴らしい回答がいくつかありました。みなさんありがとう。私は主にその簡潔さのために@aaronpsからのものを受け入れました。以下のかなり一般的な合意があるようです。 すべての間接参照されたポインタにNULLガードを強制するのはやり過ぎですが、 代わりに参照（可能な場合）またはconstポインターを使用して、議論全体を回避できます。 assertステートメントは、NULL関数の前提条件が満たされていることを検証するための、ガードに対するより賢明な代替手段です。

65 c++  coding-standards 

プラス記号+は、加算と文字列の連結に使用されますが、そのコンパニオンであるマイナス記号、は-、通常、文字列のトリミングや減算以外の場合には表示されません。その理由や制限は何でしょうか？ JavaScriptの次の例を検討してください。 var a = "abcdefg"; var b = "efg"; a-b == NaN // but a+b == "abcdefgefg"

64 coding-standards  history  operators  overload 

以前は、命令/レジスタ名を短くする非常に良い理由がありました。これらの理由はもはや当てはまりませんが、低レベルのプログラミングでは依然として短い暗号名が非常に一般的です。 どうしてこれなの？古い習慣が破れにくいからといって、それとももっと良い理由があるのでしょうか？ 例えば： Atmel ATMEGA32U2（2010？）：（のTIFR1代わりにTimerCounter1InterruptFlag）、ICR1H（の代わりにInputCapture1High）、DDRB（の代わりにDataDirectionPortB）など。 .NET CLR命令セット（2002）：（のbge.s代わりにbranch-if-greater-or-equal.short）など。 長くて、暗号化されていない名前を使用する方が簡単ではありませんか？ 回答および投票する際は、以下を考慮してください。ここで提案されている説明の多くは高レベルのプログラミングにも同様に当てはまりますが、コンセンサスは概して、1つまたは2つの単語からなる非暗号化名を使用することです（一般に理解されている頭字語は除外されます）。 また、あなたの主な議論が紙の図の物理的な空間に関するものである場合、これはアセンブリ言語またはCILには絶対に適用されないことを考慮してください。さらに、簡潔な名前が収まるが読みやすいものが図を悪化させる図を見せていただければ幸いです。ファブレス半導体会社での個人的な経験から、読みやすい名前はうまく適合し、より読みやすい図になります。 高レベル言語ではなく、低レベルプログラミングで簡潔な名前を望ましいものにする高レベル言語とは異なる、中核となるものは何ですか？

64 naming  coding-standards  low-level 

私は自分が書いていた（古風なVisual Basic 6.0）コードで次のコメントを書いていることに気付いた。 If WindowState <> 1 Then 'The form's not minimized, so we can resize it safely '... End if コメントで「私たち」を無意識のうちに使用する理由がわかりません。誰かがコードをステップスルーするのを想像しているのではないかと思っています。まるでそれらが実際に発生するのを見るのではなく、実際に各行のすべてのコマンドを「行っている」かのようです。この考え方では、私はI can resize it現在、それを「やっている」ので、またはyou can resize it、「将来」それをやっている人と話しているかのように使用できますが、これらのケースの両方は私は自分のコードを他の人に導くかのように「私たち」を使用します。 私は単純にそれを書き換えてit can be resized問題を回避できますが、それは私の好奇心を引き起こしました：コメントでこのような最初の人を使用することは一般的ですか、それとも気が散るおよび/または専門家でないと考えられますか？

63 comments  coding-standards 

コーディングの経験はほとんどありません。作業を始めた後は、ほとんどの場合、他の人のコードに取り組み、既存の機能に新しい機能を追加するか、既存の機能を変更します。実際のコードを書いた人は、私の会社ではもう機能しません。私は彼のコードを理解し、自分の仕事をするのに苦労しています。コードを変更しようとするたびに、何らかの形で作業機能を台無しにしています。他の人のコードを操作する際に注意すべきことは何ですか？

60 architecture  coding-style  coding-standards  coding  maintenance 

最近、私はPHPで、特にWordPressフレームワーク内で多くのことをしています。私は次の形式の多くのコードに気付いています： if ( 1 == $options['postlink'] ) 期待していた場所： if ( $options['postlink'] == 1 ) これは特定の言語/フレームワークで見られる慣習ですか？前者のアプローチが後者よりも好ましい理由はありますか（処理の観点、または構文解析の観点、あるいは人間の観点からも） それとも単に好みの問題ですか？ある定数に対してテストされる変数項目は左側にあると、テストを実行するときは常に良いと思っていました。「チョコレートがケーキの場合」よりも、「ケーキがチョコレートの場合」という自然言語での質問の方がよく似ているようです。

49 coding-style  coding-standards  conditions  defensive-programming 

私は別のスレッドを読んでいたが、ある男が初心者向けにC ++の本について尋ね、プログラマーの一人がこれを書いた。 いくつかの警告：「hello world」を示すすべての本を避ける #include <iostream.h> C ++ブックを開いて、上記の例のようなiostreamヘッダーが含まれていることを確認しました。 なぜそれが悪いのですか？C ++を学習するとき、他にどのような留意点がありますか？ 背景：私はCに精通しており、次の学期にC ++を学び始めます。

47 c++  coding-style  code-quality  coding-standards  headers 

関数の長さはプログラマの生産性に影響しますか？もしそうなら、生産性の損失を避けるための適切な最大行数は何ですか？ これは非常に意見の多いトピックであるため、いくつかのデータを使用してクレームをバックアップしてください。

44 programming-practices  coding-standards 

クラスのプロパティに一致するパラメーター名に関して、これに似た質問が表示されますが、C＃の大文字と小文字を除いて、パラメータータイプ名と同じパラメーター名の使用に関しては何も見つかりません。それは私が見つけることができる違反ではないようですが、それは悪い習慣と見なされますか？たとえば、次の方法があります public Range PadRange(Range range) {} このメソッドは範囲を取り、パディングが適用された新しい範囲を返します。したがって、一般的なコンテキストを考えると、パラメーターのよりわかりやすい名前を考えることはできません。しかし、「心理的距離」についてのCode Completeを読んだときに拾ったヒントを思い出します。それは言います 心理的距離は、2つの項目を区別できる容易さとして定義できます...デバッグするとき、類似する変数名間および類似するルーチン名間の心理的距離が不十分であることに起因する問題に備えてください。コードを作成するときに、問題を回避できるように、大きな違いのある名前を選択してください。 私のメソッドシグネチャには多くの「範囲」が続いているため、この心理的な距離に関して問題があるように感じます。今、私は多くの開発者が次のことをしているのを見ます public Range PadRange(Range myRange) {} 私は個人的にこの大会に強い嫌悪感を持っています。変数名に「my」プレフィックスを追加しても、追加のコンテキストは提供されません。 私はまた次を見る public Range PadRange(Range rangeToPad) {} 「私の」プレフィックスよりもこれが好きですが、それでも全体的には気にしません。私には過度に冗長で、変数名としてぎこちなく読みます。私には、メソッド名のために範囲がパディングされることが理解されています。 このようにすべてをレイアウトしたら、私の最初は最初の署名を使用することです。私には、きれいです。不要なときにコンテキストを強制する必要はありません。しかし、私は自分自身または将来の開発者にこの慣習を傷つけていますか？ベストプラクティスに違反していますか？

43 coding-standards  methods  parameters