コーディング標準が非常に役立つことが証明されていることは知っています。ただし、プログラマが好む標準にフォーマットする多くの異なるツールとIDEがあります。コードがきちんと/コメントされている限り（スパゲッティの混乱ではない）、コーディング標準の必要性は見当たりません。

コーディング標準の開発に関する議論はありますか（まだありませんが、作成を検討していました）。

ただし、プログラマが好む標準にフォーマットする多くの異なるツールとIDEがあります。

頑張ってください。私の経験では、コードをフォーマットXからフォーマットYに適切に再フォーマットできるツールはごくわずかです（ゼロ！）。邪魔になるものが多すぎます。タブとスペース、複数行のステートメントなど。GNUのC ++標準ライブラリファイルの実装をご覧ください。できることは、タブの代わりに常にスペースを使用し、外部コードの再フォーマットを気にしないことです。これで、コードは好きなように見え、外部コードは元の作者が書いたように見えます。

特定のインデントスタイルは、コーディング標準で最後に指定する必要があるものです。それは、宗教的なプログラミング戦争の開始に迫っています。コーディング標準であるIMOは、受け入れ可能なインデントスタイルの合理的なスイートを指定する必要がありますが、パッケージの作成者に詳細を任せます。インデントスタイルは、コーディング標準のごく一部です。コーディング標準のルール番号0：些細なことに気をつけないでください。インデントスタイルは小さなものです。

より大きなもの：

• どうやって名前を付けるのですか？
• 言語の特定の部分は立ち入り禁止ですか？
• コードはクリーンにコンパイルする必要がありますか？また、どのようなコンパイラー設定でコンパイルする必要がありますか？
• コードは特定のメトリックに合格する必要がありますか？
• どのようなテストが必要ですか？
• コード（コメント）と他の場所の両方で、どのようなドキュメントが必要ですか？
• 最も重要なのは、どのように標準への免除を得るのですか？

補遺
おそらく、さらに重要なのは、コーディング標準に入れないことです。要件の書き方などのトピックは、コーディング標準には属しません。テストの詳細も属していません。プロジェクトでは、プロジェクト管理計画、テスト管理計画、検証および検証計画などの代用としてコーディング標準を使用しないでください。コーディング標準の目標は、コードの安全性、品質、理解可能性、保守性、およびその他の「虚偽」。これが起こらないようにする方法はたくさんあります。ほんの数例：規格を一部の国の税法と同じくらい複雑な本にして、宗教戦争のプログラミングを扇動し、命名規則が悪い。

コーディング標準は、意図しない結果をもたらす可能性があります。例：プロジェクトエンジニアのバカは、「マジックナンバーなしのルール」を解釈しif (index == 0) {...}、for (ii = 0; ii < 3; ++ii) {...}変更する必要があり、笑わないif (ZERO == index) {}でfor (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}ください。私はそれが起こるのを見てきました。今日、コーディング標準を作成するときは、この種の愚かさを打ち消すためのルールではなく、「魔法の数字のないガイドライン」です。

コーディング標準は、悪いプログラミングスタイル/危険なコーディング手法に対する第一の防御ではありません。コードレビューです。何年にもわたる自動化にもかかわらず、人間の目の主観的なセットがコードの塊を見て判断を下すことほど良いものはありません。

コーディング標準は、単に好みのパラメーターに関するものではありませんindent-命名規則、コメント規則、およびイディオム、言語機能の使用などに関する多数の可能な推奨事項も含まれます。

さらに重要なのは、どこかでこれをすべて文書化する必要があることです。そして最後に、すべての人がコードをそのように再フォーマットするIDEを使用するわけではありません...

チーム内で一貫したスタイルを使用すると、コードが読みやすくなります。コードが読みやすくなると、チームの生産性が向上します。コードをメンタルに解析する必要がないため、生産性が向上します。また、コードを確認および保守する際に、構文ではなくロジックに集中できます。

IDEが各自の選択に合わせてコードを再フォーマットできるようにする場合、次の2つの問題のいずれかが発生します：保存するときに常に元のフォーマットに戻すことを確認するか、diffに多くのノイズが表示されるという事実に悩まされるか、コードのロジックの変更点を確認するのが難しくなります。

短い回答：はい、品質を反映しています。

それは何で、なぜ必要なのですか？

コーディング標準は、高品質のソフトウェアの非常に重要な部分です。彼らは何増加の生産性を維持するためにメイクコードより簡単に、開発プロセスでは、1人またはチームに縛られるのコードを保持します。コーディング標準の一貫性は、時期尚早に作成されたコードと巧妙に作成されたアートを区別します。

OK、すべての開発者はコーディング規約が良いことを知っています。しかし、標準はどこから来るべきでしょうか？

ほとんどの場合、製品を所有するベンダーによって決定されます。すべての開発者は、多くの業界コーディング標準から選択できます。Microsoft、Oracle、およびSun Microsystemsの一部の企業はガイドラインを提供しています。

コーディング標準の開発に関する議論はありますか（まだありませんが、作成を検討していました）。

はい、使用することが推奨されている業界標準があります。ただし、各コーディング標準は開発プラットフォームに固有です。したがって、コーディング標準はほとんどが言語固有です。たとえば、Javaには.NETとは異なる標準があります。たとえば、C＃.NETはthis referenceでその標準を使用しています。

共通の基準

共通の標準は、プログラミング言語に依存しません。ベンダーが提供する標準（別名言及された業界コーディング標準）に加えて、ハンガリー語表記やキャメルケースなどのさまざまなプログラミング表記があります。Microsoft .NETコーディング標準は当初、キャメルケース表記に基づいていたと思います。

チームのコーディング標準とガイドライン

すべての開発チームは、プロジェクトの開始後すぐにコーディング標準に同意する必要があります。コーディングガイドラインは通常、チームリードまたは会社のチーフアーキテクトによって作成されます。通常は、必要に応じてフォローおよび改善されるオープンドキュメントです。たとえば、当社には、このドキュメントがアップロードされ、会社の開発者が利用できるWikiページがあります。

私は物議をかもす意見を持って、コーディング標準を必要としないと言います。あなたが言うように、ルールはIDE強制ガイドライン、すべての会社の全員が従うべき一般的なベストプラクティスであるか、有能なチームの複数の人が行うべきケースごとの判断コールですペアプログラミングまたはコードレビュー経由。

この変数にどのように名前を付けたらよいでしょうか？どの言語機能を使用する必要がありますか？避けるべきですか？どのテストが最適ですか？これらは、私たちが今取り組んでいる狭く定義された問題に遭遇するまで、答えられないままにしておくのが最善です。

これらの細かな決定から結晶化され、現在の問題領域と使用中の技術との共通点に基づいて、チーム内で非公式の標準/パターンが発生する場合があります。これらを体系化することは、何百もの微小な決定に基づいてこれらのプロジェクトで使用され、これらのチームによって非公式に採用された命名基準、適切な言語サブセットなどのようなものが、前進するすべてのプロジェクトを導くべきだと考えることを意味します。

原理的には素晴らしいことのように聞こえますが、実際には政治の磁石になります。誰にどのツールを使用させることができますか？他の人に何を強制的に避けたいですか？これらの質問に全員が同意すれば、標準は必要ありません。ただやるだけです。私の経験では、開発者のあるサブセットが別のサブセットを制御したいという要望から標準が生まれました。通常、このタイプの政治とそれに続く技術的ポリシングは、ガイダンスを提供するのではなく、イノベーションを抑制するだけです。

実際のガイダンスが必要な場合は、多くの役に立たないルールを含む標準を読む代わりに、チームの有能なメンバーを見つけて、彼らにどう思うか尋ねてください。彼らは何によって焼かれましたか？彼らはあなたにコードを書くことをどのように示唆していますか？あなたはそれをバックアップするために多くの貴重な経験を持つ様々な有用な答えを得るでしょう。一般的な経験に基づいて多くの交差点が表示されます。標準によって強制される単一文化の代わりに、問題を解決するための多くの有効な方法を見るのに役立つ多くの多様性も見られます。

そして、誰かが「標準」のルールの原因を何もしないように言ったが、彼らの主張に対する経験または合理的なバックアップがない場合、それらを無視します。ここでは、この標準は誰にも役立っていないか、誰も優れた開発者になりません。

商用航空機がフライバイワイヤになったので、パイロットの入力に基づいて飛行機を操縦するプログラムが機能することを望みます。プログラマがそのようなコードを書くとき、一般的に回避可能なプログラミングエラーを避けるために、厳密なルールセットに従うことを望みます。これを行う1つの方法は、コーディング標準を使用することです。

参照：連邦航空局で提案されているCおよびC ++コーディング標準

もっと言う必要があります。

注：オンラインでFAAから実際の標準を見つけることはできませんでしたが、見ました。

私にとっては、規律と規律の問題は常に助けになります。それは、あなたが生み出す仕事の質を反映しています。

そうは言っても、使用中のIDEやツールを表示するコーディング標準を作成します。さらに、開発者ごとにIDEを同一に構成する必要があります（たとえば、各開発者のIDEはインデントにすべてのタブまたはすべての空白を使用し、すべてのIDEのタブ長は同じにする必要があります）。

また、コーディング標準をある程度遵守するのに役立つチェックインスクリプトを開発して使用することもできます。たとえば、チェックインファイルをバージョン管理システムに実際にコミットする前にインデントを修正できます。

コーディング標準はこれ以上重要ではありません！私はCakePHPの熱心なユーザーであり、バージョン間の変更セットを確認したいのですが、開発者はそこで標準に従っていません。

実際、スタイルの違いに非常に腹が立ったため、コーディング規約に関する短い説明を書かなければなりませんでした。新しい開発者を既存のチームに連れて行くには多くの時間とお金がかかります-標準なしで新しい開発者を連れてくることを想像してください...コードを学習することは次に不可能になります。