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

小規模な開発チーム（開発者3人のみ）があり、最近、新しいチームメンバーを獲得しました。彼は賢いコーダーですが、彼のコーディングスタイルは私たちのものとはまったく異なります。既存のコードベースには、ほとんどが読み取り可能で、クリーンで保守可能なコードが含まれていますが、新しいチームメンバーは多くのファイルをすばやく変更し、,いハックとショートカットを導入し、あらゆる場所で定義を使用し、間違った場所に関数を追加します。 私の質問は、他の人が以前にそのような状況を経験したことがあるかどうか、そして誰かが彼と話す方法に関するヒントを持っているかどうかです。

14 coding-style  coding-standards 

競合マーカーを検討してください。すなわち： <<<<<<< branch blah blah this ======= blah blah that >>>>>>> HEAD この質問を投稿する動機となった特定のケースでは、担当のチームメンバーがアップストリームからブランチへのマージを完了したばかりで、場合によっては、これらをコメントとして、今までの内容に関する一種のドキュメントとして残していました解決しました。彼はそれをコンパイルされた状態のままにして、テストに合格したので、あなたが思うほど悪くはありません。 本能的には、私は本当にこれに異議を唱えましたが、悪魔が自分自身を擁護しているので、なぜ彼がそれをしたのかがわかります： マージの結果として変更されたものを他のチーム開発者に強調するためです。 特定のコードに精通している人は、コメントが示す懸念に対処できるため、推測する必要がありません。 アップストリームマージは適切な痛みであり、すべてを適切かつ完全に解決するための時間を正当化するのが難しい可能性があるため、いくつかの半完全なFIXME通知が必要です。 私の反対は本能的でしたが、それを合理的に正当化するか、自分の立場をより賢く見たいと思います。誰かが私にいくつかの例や、誰かがこれをやっていると悪い時間を過ごした経験や、それが悪い習慣である理由を教えてもらえますか（または悪魔の擁護者を演じてそれをサポートすることができます）。 私自身の当面の懸念は、関係するファイルの1つを編集し、変更を取得し、実際の競合を取得したが、コメントされたファイルも取得した場合、明らかに迷惑になることでした。そうすれば、本当に非常に面倒なファイルになっていたでしょう。幸いなことにそれは起こりませんでした。

14 version-control  comments  coding-style 

同じ名前の変数とフィールドを区別する必要がない限りthis.、C＃でフィールドまたはメンバーアクセスの前に配置することはありません。これはm_、C ++で一般的に使用されていたプレフィックスと同じであり、メンバーであると指定する必要がある場合、クラスが大きすぎると思います。 しかし、私のオフィスには多くの人々が強く反対しています。 現在のベストプラクティスと見なされるものは何this.ですか？ 編集：明確にするために、私は絶対に使用することはm_なくthis.、絶対に必要な場合にのみ使用します。

14 c#  coding-style 

最近、ソフトウェア開発者として最初の仕事を始めたとき、コードの命名規則に従う必要がないと言われたとき、私は少し投げられました。他のより大きなプロジェクトに取り組んでいるグループによって書かれたコードは命名規則に従っていましたが、私は新しいスタンドアロンのアプリケーションを書くために持ち込まれたので、それは特に重要ではないという感じでした。それが私の心配の最後だったので、私はちょうどその既存の慣習を取り、それで走りました。 int nTickCount bool bConnected object[] m_aItems fSum += fWeight * fValue class cManager enum etSystemStates etSystemStates eState cManager.cs しかし、実際に価値があるのでしょうか？この種の命名規則に従うことがエラーの理解と検出に与える正味の効果を判断するのは難しいと思いますが、視覚的には、それはちょっといように見えます。さらに、cSomethingと呼ばれるプロジェクトにすべてのクラスとファイルがあることは、非常に簡単です。 私が採用しているアルゴリズムやアーキテクチャのような明らかな違いをもたらすものと比較した場合、それはリモートで大したことではないという幻想ではありません。しかし、私が書いたコードのすべての行に影響する規則は、正しく理解する価値があるようです。 使用する必要がある場合、最もエレガントで効果的な命名規則は何ですか？タイプやスコープを示していますか？

14 language-agnostic  coding-style  notation  hungarian 

ボブおじさんのきれいなコードを読んでいます。私は英語を母国語としないため、次の声明を理解できませんでした。 クラスとオブジェクトのような名詞や名詞句の名前を持つ必要があり Customer、WikiPage、Account、とAddressParser。避け言葉が好き Manager、Processor、Data、またはInfoクラスの名前インチ クラス名は動詞であってはなりません。 私が知っているように、のいずれもManager、Processor、Data、およびInfo動詞である、そうではありませんか？彼が強調したい実際のポイントは何ですか？

14 coding-style  terminology  code-quality  naming 

コーディング標準/スタイルは、静的分析ツール（例：PMD、StyleCop / FxCop）を実行し、標準に従っていない場合はビルドに失敗する継続的統合サーバーによって実施されるべきですか？ビルドを失敗させるためにどの種類のルールを使用すべきではありませんか？

14 coding-style  coding-standards  continuous-integration 

おそらく、基本的な状況は誰もが知っています。チーム内の特定のコーディング標準について合意したので、今度はすべてのコーディング標準に従うようにします。 重いペアプログラミングを介してそれを行うものもあれば、コーディング標準のリストを維持し、手動でレビューするものもあります。また、Visual Studioの静的コード分析ツールを使用して、コーディング標準が適用されていることを確認するものもあります。 コーディング標準を確保するためのベストプラクティスは何ですか？どのツールを使用しますか？すべての開発者が知っておくべき重要なツールはありますか？開発ツールにコードの標準化をどのように統合しますか？

14 c#  .net  coding-style 

私はAngularJSプロジェクトに取り組んでおり、属性は私のHTML要素の多くで多数あります： <button type="submit" ng-click="Page.UI.DetailView.ExecuteFunction()" ng-disabled="step5.$invalid" class="btn btn-success pull-right"> Submit this Product </button> これらの属性の順序に標準化された規則はありますか？アルファベット？意味によってグループ化されていますか（例：すべての角度属性を一緒に）？最初に標準のHTML属性（たとえば「タイプ」）

13 programming-practices  coding-style  html 

問題：2人の開発者=>インデントに関する3つの意見、改行の有無など 私たちは通常、プロジェクトで3人または4人で作業し、それぞれに独自のコードスタイルがあります。共通の解決策はコードスタイルに同意することであり、誰もが使用する必要がありますが、クリエイティブプログラマーにそれらに合わない訴訟を強いることは望みません。 質問は次のとおりです。各プログラマーが独自のスタイルを生きながら、リポジトリ内に共通のコードベースを持っている方法はありますか？私は、いくつかのgit / svn / whateverプラグインについて考えます。これは、チェックアウト時とコミット時に個人的なスタイルと一般的なスタイルの間で変化します。このアプローチのトリッキーな部分は、ファイルのバージョン間の正しい差分をサポートすることであるように思えます

13 coding-style 

私は2か月前に6人の開発チームに参加しました。人々は素晴らしいです、すべてが良いです。しかし、私はますますアドホックな考え方を観察します。スタッフはすぐに修正されますが、将来の使いやすさを犠牲にして、テストはほとんどなく、2人の人が喜んで認めています。 これに対処するには？私は例を挙げてリードしたいと思いますが、時間は限られています-ものを設計し、実際に実装するのが好きです。しかし、私はアドホックな考え方が私に感染していることを恐れており、デザインとコードの明快さと単純さを追求するのではなく、それを確立するのは簡単ではありません部外者は分離することができます-スケジュールと管理のためだけに。

13 architecture  coding-style  management  technical-debt 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私はPythonとJavaで多くの仕事をしており、両方の言語には識別子で大文字を使用する方法に関するかなり一般的な（普遍的ではない）規則があります：PascalCaseクラス名とALL_CAPS「グローバル」定数の両方で使用しますが、他の識別子には多くのJavaコードが使用するのmixedCaseに対し、多くのPythonコードはを使用しunderscore_delimitersます。特定の大文字と小文字を強制する言語やライブラリはないことは知っていますが、使用している言語の標準的な規則に従うと、コードがはるかに読みやすくなることがわかりました。 今、私はC ++でプロジェクトを開始していますが、同じアイデアを適用したいと思います。大文字と小文字の区別について知っておくべき最も一般的な規則はありますか？

13 c++  coding-style  coding-standards 

特にクラスメンバーのXMLコメントに関しては、コードをより適切に文書化することを目指していますが、多くの場合、それは愚かなことです。 イベントハンドラーの場合、命名規則とパラメーターは標準的で明確です。 /// <summary> /// Handler for myCollection's CollectionChanged Event. /// </summary> /// <param name="sender">Event Sender</param> /// <param name="e">Event Arguments</param> private void myCollection_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e) { // actual code here... } また、要約が冗長になるように、明確に名前が付けられた単純なプロパティ（IMO）も頻繁にあります。 /// <summary> /// Indicates if an item is selected. /// </summary> public bool ItemIsSelected { get { …

13 c#  coding-style 

読みやすくするために、複雑な複合AND / OR ifステートメントをどのようにスタイルしますか？どのようにインデントし、改行をどこに配置しますか？私の特定の状況は次のようなものです。すべてを1行に分割するよりも間違いなく優れていますが、それでも面倒です。 if ( ( x == y && a != b && p.isGood() && ( i + u == b || q >= a ) ) || k.isSomething() || m > n ) { doSomething(); }

13 coding-style  indentation 

現在、多くの異なるセクション（すべて異なる書式設定が必要）を含む一連のレポートに取り組んでおり、コードを構造化する最適な方法を見つけようとしています。過去に行った同様のレポートには、レポートのすべてのデータ操作と書式設定を行う非常に大きな（200行以上の）関数があり、ワークフローは次のようになります。 DataTable reportTable = new DataTable(); void RunReport() { reportTable = DataClass.getReportData(); largeReportProcessingFunction(); outputReportToUser(); } これらの大きな機能を小さなチャンクに分割できるようにしたいのですが、再利用できない機能が何十個もあり、同様の機能を「ここですべて実行」するだけで済むのではないかと心配しています。次のように、これらすべての小さな関数を呼び出します。 void largeReportProcessingFunction() { processSection1HeaderData(); calculateSection1HeaderAverages(); formatSection1HeaderDisplay(); processSection1SummaryTableData(); calculateSection1SummaryTableTotalRow(); formatSection1SummaryTableDisplay(); processSection1FooterData(); getSection1FooterSummaryTotals(); formatSection1FooterDisplay(); processSection2HeaderData(); calculateSection1HeaderAverages(); formatSection1HeaderDisplay(); calculateSection1HeaderAverages(); ... } または、さらに一歩進んだ場合： void largeReportProcessingFunction() { callAllSection1Functions(); callAllSection2Functions(); callAllSection3Functions(); ... } これは本当に良い解決策ですか？組織的な観点から私はそれがそうであると思います（すなわち、すべてはそうでなければそうであるかもしれないよりもはるかに組織化されます）が、コードの読みやすさに関して私は確信していません（潜在的に他の関数を呼び出すだけの関数の大きなチェーン）。 考え？

13 coding-style 

この質問は、Java に関する質問にfinal触発されたものです。 C / C ++では、const可能な限り使用する必要がありますか？ パラメータでの使用constに関して、関連する質問が既にあることは知っています。残念ながら、その質問とその回答は関数のパラメーターに関するものだけなので、私の質問には完全には答えませんが、他のケース（たとえば、ローカル変数）についても知りたいです。 また、その質問に対するほとんどすべての回答constは、変数のアクセス可能性に関する有用な情報が含まれているため、使用する必要があると述べています。しかし、これはJavaでfinalを使用することに関する回答と矛盾するようです。このfinal情報は、余分な情報が含まれていない場合は不必要であり、コードを短く簡潔にするために省略する必要があると述べています。 それで、const可能な限り使用すべきですか？もしそうなら、なぜconstC ++でのアドバイスfinalがJavaでのアドバイスと異なるのですか？

13 c++  coding-style  const