開発者の自主性を優先してコーディングスタイルを推奨するべきですか、それとも一貫性を優先して推奨しないのですか？

開発者は、次の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', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

別の書き込み：

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

私が話していることをあなたが知っていると確信しています。私はそれをコーディングスタイルと呼んでいます（それが何と呼ばれているかわからないため）。しかし、私たちがそれを呼ぶものは何でも、それは良いですか悪いですか？それを奨励することは、開発者の生産性を高める効果がありますか？システム全体のスタイルに一貫性を持たせるために、開発者に指示どおりにコードを記述してもらう必要がありますか？

コーディング標準文書が役立ちます。それはだ、ほとんどそれは誰もがあまりにも面倒とするとき、それは誰にもあまり痛みを生じさせないことなく、全体のことを思い出すことができ、短い十分だときに便利。

組織内でコードをインデントする方法、名前を大文字にする方法、ループを実装する方法、コードにコメントする方法は、それほど重要ではありません。役に立つのは、他の人とほぼ同じように見えるコードを誰もが作成できるようにすることです。

• それは、ブレースがどこにあるべきか、そして誰か他の人のコードを見るたびにそのようなことについてのあなたの期待を再調整するのに1分を費やすことを避けます。
• 同じファイルに複数の異なるスタイルのコードが含まれることを回避します。
• おそらく最も重要なことは、標準を作成することで、コードレビュー中のコーディングプラクティスに関する議論を回避できることです。

繰り返しますが、標準が何であるかは、ある種の単純で単純な標準を持つことほど重要ではありません。したがって、すべての開発者を部屋に入れて、標準がどうあるべきかについて議論させてください。この会議は無期限に開催される可能性があるため、ルールは次のとおりです。

• ミーティングの終わりまでに決定されないものはすべてマネージャーによって決定されます。
• 会議は2時間後、または誰かが叫び声や泣き始めたときのいずれか早い方で終了します。
• 標準全体は、1枚または2枚の用紙に（妥当なタイプサイズで！）収まり、絶対に必要な場合にのみ両面印刷されます。

誰かの採用を検討する| 他の | 規格独自のコーディング標準会議の開始点として、または完全に会議を回避する方法として、どちらか。

合意が得られると、開発者は自分でポリシングできるようになります（また、期待されるはずです）。時々標準から逸脱することは大したことではありません（正当化される可能性もあります）が、標準を支持してお気に入りの個人的なスタイルを放棄することを拒否するだけでは、漏れやすい水道管などでオフィスにすぐに移転する必要があります。

デミアン・ブレヒトは糸くずツールを指しています。これらは、コーディング標準文書を完全に補完します。コーディングスタイルの標準に準拠するのは良いことです。危険な慣行に関連するコーディング標準に従うことが重要です。作者以外はコードのすべての行がスタイルの基準を満たしていることを確認しませんが、可能性のあるバグを自動的にキャッチするために、チームのワークフローにリントツールを組み込むことを検討する必要があります。さらに、ツール自体が受け入れられたプラクティスを体系化できるため、コーディング標準でそれらをすべて個別にリストする必要がありません。ツールの構成を指定するだけです。

注：「コーディング標準」という考え方は、プログラミングに固有のものではありません。「コーディング標準」は多くの分野で使用され、組織内で使用されることもあれば、業界全体または職業全体で使用されることもあります。いくつかの例：

• 裁判所への提出書類や成績証明書などの法的文書は、特定の形式に準拠しています。
• 脚本と脚本は、真剣に受け止めるために特定のスタイルで作成する必要があります。
• 技術図面には、多くの場合、標準形式のタイトルブロックが必要です。
• 書誌フォーマットは標準化されています。

それぞれの場合（および他の多くの場合）、有能な開業医は、期待される基準を満たさない「コード」を容易に理解できます。なぜ多くの業界が、コンパイラで解析する必要さえないドキュメントの詳細な要件を記述することに固執しているのですか？そのため、スタイルの問題。情報を標準スタイルで提示することで、読者はコンテンツに完全に集中できるようになり、読みやすくなり、理解しやすくなり、エラーが減ります。

スタイルは関係ありません。

そこに、私はそれを言った。

30年後、数百のクライアントサイトと、それらの年にわたる（推定）500（またはそれ以上）のチームメンバーのコードの後、そのスタイルは重要ではないことがわかりました。

最初に動作させます。

最適な量のリソース（つまり、適切なデータ構造、適切なアルゴリズム）を使用するように取得します。

他のすべてが解決された後、「スタイル」をめぐって大騒ぎ。「スタイル」の大騒ぎはツールのみで、決して手動ではありません。

コーディングスタイルがあり、コーディングのにおいがあります。私が見つけたのは一度もありませんでした：

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

私の以前の雇用主は、if()ブレースなしのマルチラインの使用を厳格に禁止していました。これは、「もう一度やり直してください」というタイプの障害と見なされていました。許可されたコンストラクトは

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

これは、上記で示したようなエラーが原因で発生し、ポータルのメインページが停止するまで数時間かかりました。

いつもやるべきことがあります。のようなswitch()：

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

一方、タイピング：

     case 1:
         something();
     case 2:
         something();
     break;

casewith を閉じないこと//fallthroughはバグと見なされます。

一般的に、コーディング標準がありますが、これは無視したり、創造的に解釈したり、特定のニーズに合わせて修正したりできるガイドラインです。そして、「臭い」に関するセクションがあり、それは厳密に従うべきです。

優れた先行設計で一貫性を作成します。あなたが質問で説明するのは、ミクロ管理にほかなりません。私は多くのWeb開発を行っています。したがって、サービスとして公開されるRESTfulおよびCRUD開発を優先します。これにより、さまざまな方法で使用できる、シンプルで明確に定義されたエンティティが保証されます。

この設計により、実装の詳細を他の開発者に委任することもできます。このようにして、システム設計全体を作成するのではなく、空白を埋めています。

全体的な設計が欠如していると、システムの不整合が生じます。基本的な反復とループ構造の批判は、システム設計の改善にはほとんど役立ちません。これらの種類の問題は、StyleCopというハンドオフアプローチを使用することで解決できます。

システム設計全体の比較的単純な図を描くことができますか？新しいチーム開発者に関係する要素/エンティティを説明するデザイン。できない場合、または非常に複雑な場合は、設計が不足しています。

私見それは依存します...

最初の2つの例は、個人的な好みの問題ではありません。

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
   // ...and this line as well... oops! this will actually execute either way

そして、これはデバッグするのにあまり便利ではありません：

new HelperClass().DoSomething(GetSomeData()); // etc.

必要な場所に簡単にブレークポイントを設定することはできません。これが1回限りの場合-十分に公平ですが、スタイルの問題として議論し、このようなものが至る所にあると、デバッグは必要以上に不快になります。

3番目の例（vs foreachの場合）については、好みの問題だと思います。

どちらでもない。面倒で、つまらない、細かな管理、そして最悪の無駄時間を避けるために、厳しいコーディング規則を避けます。あなたの自律の感覚はあなた自身の問題です。あなたが自分自身について気分が良くなるようにしたい場合は、お気に入りの飲み物を一杯買います。それ以外は、何かを成し遂げてください。

規則、変数名、クラス名などを使用することをお勧めします。ただし、提供する例のようなコーディングスタイルはかなり単純であり、コードの可読性や効率には影響しません。一方、特定のスタイルを強制することによるオーバーヘッドと、それに従うことに対する開発者の努力が組み合わさると、問題が発生します。

業界標準のリンティングツール（明らかにF＃Cop for C＃）を使用します。多くの人々が取り組んでいる大規模なプロジェクトでは、すべてではありませんが、一貫性は重要です。

あなたが自分のプロジェクトや小さなチームで作業しているだけなら、多くの人がそれはやり過ぎだと主張するでしょう。そうでないと思います（個人開発者のプロジェクトでも、Python にはPEP8を使用しています）。

ただし、あなたが与えた例のほとんどは、単に重要ではないので、リンティングツールに捕らえられることはほとんどないでしょう。

統一されたコーディングスタイルを強制することは常に困難です。理想的には、そのようなありふれたタスクは、処理するツールに任せるべきです。Go言語コミュニティにそのことを称賛します。

両方の混合物です。それが標準だからといって、それを読みやすく保守しやすくするわけではありません。まだ注入された標準がない場合、またはそれが不完全で読めない側面がある場合、改訂が適切です。

最終分析では、プログラミングを推進するのはプログラマーです。スタイルの問題は存在しますが、プログラムを公開することに二次的なものです。

プログラマーにいくつかのスタイルのガイダンスを提供すると役立ちます。これは、プログラマーが仕事に就く前に、特に環境やプログラミング自体に比較的初心者である場合に行うことができます。ガイダンスがあれば、一部のプログラマーは非常にスタイルを意識しますが、そうでないプログラマーもいます。プロジェクトの最初に与えられたガイダンスは、プログラマーの最初のグループを助け、それによって全体的なタスクをより簡単にします。2番目のグループにはほとんど役に立たないかもしれません。それは、創造性、彼らが適合性に欠けているものを（願わくば）補うでしょう。

プロジェクトの規模と、プロジェクトに取り組んでいる人の数にかかっていると思います。熟練したプログラマーは、両方の異なる形式スタイルを調べて、両方で何が起こっているかを知ることができますが、目で簡単にキャッチできるように、連続性が必要です。カールブレースなしで単一行ifstatmentsを実行する場合、そのプロジェクトはそれらを使用すべきではありません。私はそれらを手に入れることができるので、私は物事が明確なカットと非常にコンパクトに見えるのが好きです。統計情報が1行である場合、次のようになります。

if() {}
else() {}

あるいは：

if() {} else () {}

ただし、単一行ifでは、マルチラインifの間隔を使用しないでください。それは私が物事を行う方法です。オブジェクトが呼び出される方法を気にしません。それは、そのオブジェクトが呼び出される回数に依存します。それが数回呼び出される場合、私はむしろオブジェクトを開始し、それがコンストラクターを持っているかどうかに依存します。コンストラクターがあり、次を呼び出す場合：

Object.method();
Object.method2();

次に、オブジェクトを完全にインスタンス化することで回避できた場合に、オブジェクトコンストラクターメソッドを2回呼び出しました。

foreachとforループに関しては、lanaugeについてもいくつかの言語がforeachループの配列を見るときにより良い制御を与えるので、temp配列にキーと値があります。また、ループを見て、その呼び出し回数を正確に知ることができるため、一部のラナグが何らかの最適化を持っていることを知っています。

最初の例は素晴らしいものではありませんが（変更中にバグが発生しやすいという議論にはある程度の重みがあります）、一般に、開発者がわずかに異なるコーディングスタイルを使用することを好むようになりました。

他のチームメンバーのコードを使用した後、場合によってはわずか数か月で、基本的にインラインで機能し始めgit blameます。私の会社に10年以上在籍した後、私はおそらく、80万行以上の正確さで、50万行のコードのどこにでもクラスを見ただけで、それを見ることができます。

同意しないスタイルを使用するコードを見始めると、「ランプ時間」が少しありますが、その時間に実際にやっているのは、「ああ、これはJohn Doeのコードのようです」彼はスタイルXを使用しますが、スタイルYなどは使用しません）。そして、それはコンテキストのヒープ全体をもたらします。最初の概算では、Johnのコードに何を期待すべきか、つまり、彼がコードベースの他の部分をよく理解し、どの部分を理解していないか、SQLの第一人者かGUI初心者かなどを知っています。

フォーマッタを介して全員のコードを実行すると、基本的にこの情報git blameが取り除かれ、実行の手間がかからない可能性があります。

これは本当に組織のタイプに大きく依存します。

あなたがスーパーヒーローの小さなグループなら、どんなタイプのスタイルでも構いません。全員が独自のスタイルを持ち、それが優れたものであり、内部的に一貫している場合、それが必要なすべてのプロセスです。スーパーヒーローは、「ジェーンには括弧があるので、これが彼女の意味です」または「ジャックは変数にcamelCaseを使用します」と言います。

誰もがB +プレイヤーになるためには、普遍的な標準が最適です。これにより、スーパーヒーローが倒れます。ただし、1人のAプレーヤーと6人のBプレーヤーと6人のCプレーヤーを平均してB +にしたい場合は、一貫した基準が必要です。この例では、Aプレイヤーができるだけ早く全員のコードを確認できるように、全員が同じことをするようにします。

あなたの多くは、「でも待って、BプレーヤーとCプレーヤーを捨ててみませんか？」

現実には、スーパーヒーローはそれほど多くありません。Googleでそれらを見つけて育てるにはお金がかかるかもしれませんが、Ma Bellに新しい請求システムを導入すると、後者のチームの方が費用対効果が高くなります。（そして、もしあなたが本当にスーパーヒーローを持っているなら、それらの4つか5つはダースの後輩の2倍の費用がかかります）