あなたの会社にはコーディング標準がありますか？[閉まっている]

最近、Microsoftがコーディング標準ドキュメント（All-In-One Code Framework Coding Standards）をリリースしたのを見て、考えました...私が働いている会社には、正式なコーディング標準がまったくありません。開発者は数人しかいませんが、私たちは同じようなスタイルに進化するのに十分な長さで協力してきましたが、それは決して問題ではありませんでした。

あなたが働いている会社には、文書化されたコーディング標準がありますか？いいえの場合、なぜですか？標準があれば違いはありますか？ゼロから標準を書く価値がありますか、それとも別の標準を独自のものとして採用する必要がありますか（つまり、Microsoftの標準を自分のものにする）。

チームは、いくつかの問題を回避するために、言語ごとに単一のコーディング標準を持つことが重要です。

• 標準がないと、コードが読めなくなる可能性があります。
• 標準に関する意見の不一致は、開発者間のチェックイン戦争を引き起こす可能性があります。
• 同じクラスで異なる標準を見ると、非常にイライラする可能性があります。

私は、ボブおじさんが標準について言っていることの大ファンです。

1. 最初の数回の反復でそれらを進化させます。
2. 会社固有ではなく、チーム固有のものにしてください。
3. 回避できる場合は書き留めないでください。むしろ、コードを標準の取得方法にしてください。
4. 良いデザインを立法化しないでください。（たとえば、gotoを使用しないように人々に伝えないでください）
5. 標準はコミュニケーションに関するものであり、それ以外のことは誰もが知っていることを確認してください。
6. 最初の数回の反復の後、チームをまとめて決定します。

「3スペースのインデントを使用し、開き括弧を次の行に使用する」というだけでも、コーディング標準を用意することが不可欠だと思います。いくつかの利点：

• ファイル間でコーディングスタイルを切り替えるのは面倒なので、コードベース全体の読み取りがはるかに簡単になります。
• 競合するスタイルを持つ2人の開発者によって更新されたファイルは、最終的にそれらのスタイルが混在する傾向があるため、単一のファイルの読み取りが容易になります。タブとスペースが混在するファイルを読んで（そして後で編集するのは）面倒です。
• 暗黙の標準ではなく、明示的な標準がある場合、新しい開発者が適切なスタイルを使用しやすくなります。
• 一貫した命名規則により、関数/変数の検索がはるかに簡単になります。ArraySortまたはarray_SortまたはsortTheArrayまたはdoSortArrayまたは...でしたか？

既存の標準を採用するかどうかという点では、それは本当に重要ではありません。一貫性が重要です。開発者が多数の異なるスタイルを使用している場合、既存の公開されたスタイルを選択することもできます。かなり一貫したスタイルに進化した場合は、それを書き留めて使用してください。

「私たちはXショップです」には同意しないため、すべての言語で同じようにコードをフォーマットします。

個人的に私は、ほとんどの言語が異なる受け入れられたスタイルを持っていることを発見しました。

CプログラマーがCフォーマットでJavaコードを書くとき、私は本当に我慢できません。Javaのように見えないだけでなく、Javaで他のCのようなプラクティスを使用できると考えるようになります。

標準があれば言語ごとにすべきだと思う

私の元雇用主はコーディング標準を持っています。私も自分で正式に文書化することを検討しています。

または、あなたが提案するように、まともな既存の標準を見つけ、それを修正/採用します。会社については、既存のコーディング標準を検討することをお勧めしますが、独自の特定のニーズに合わせて作成/変更します。ゼロから作成する必要は必ずしもありませんが、会社が作成するソフトウェアの種類に対してコーディング標準が意味をなすように注意する必要があります。

はい、コーディング標準があれば違いがありますが、それは特効薬ではありません。スタイルの衝突はそれほど多くないため、コードは読みやすく、いくつかの一般的な間違い/落とし穴は回避できます。標準であっても、コーディングスタイルには多少の違いがありますが、そのばらつきは少なくなります。目標は、すべてのバリエーションを避けたり、あらゆる可能性のある状況に備えようとすることではありません。コーディング標準が複雑すぎると、まったく標準よりも悪化する可能性があります。

残念ながら違います。だから、誰もがスペース、インデントなどを使用する独自の方法を持ち、すべてが混在しています（この方法では、コード行の作成者が誰であるかを知るために「非難」関数を使用する必要さえありません！）

しかし、最悪の場合でも、誰かがイタリア語で変数名とクラス名を書き、他の人が英語で書きます...

私はいつも自分のスタイルを、使用している言語、ライブラリ、フレームワークのスタイルに合わせて、ソースコードが統一されたプレーンなものに見えるようにします。

これは、オールインワンコードフレームワークに固有のコーディング標準ドキュメントであることに注意してください。

私はさまざまな企業で働いてきましたが、その一部は既存の標準を使用し、一部は（ほとんど）標準の開発を支援しました。ほとんどの場合、.NETベースの開発を行っている場合（およびそうでない場合でも、ほとんどのルールは引き続き適用されます）、フレームワーク設計ガイドラインをご覧ください。これは公開APIの作成に固有のものですが、ほとんどのガイドラインはどのコードにも等しく適用されます。

コード標準の最大の関心事は、それを比較的シンプルでわかりやすいものにすることです。開発者が提示されたガイドラインを内部化できるようにしたいので、50ページ以上のドキュメントを提供しても意味がありません。背景や例などを提供したい場合でも、そのドキュメントを作成できますが、箇条書きのガイドラインに要約したものも必要になります。また、コーディング標準は、技術の変化に応じて変更する必要がある柔軟で生きたドキュメントでなければなりません。

コーディング標準の議論は次のようになります。

• はい、あなたはそれらを必要とします、一貫性ときれいなコードは良い開発の基礎です。
• 彼らは何をしているほとんどは、あまりにも長い間、誰もが同じ基準を次のように、重要ではありません。
• 自分で書いてはいけません、あなたは終わりのない痛みを伴う議論になってしまいます。人気のあるものはたくさんあります。
• （MSDNのような）パブリックスタンダードを使用すると、議論の余地のない不可知論者のサードパーティが得られます。それらについて議論したい場合は、ポイント2を参照してください。

Visual StudioのC＃で開発している場合、StyleCopは特効薬です。ReSharperも使用している場合は、StyleCop for ReSharperプラグインは最高です。

私たちはブラブショップなので、ブラブプログラミング規則を使用します。

今ではポール・グラハムと友人たちは私たちよりもはるかに賢いですが、プログラマーをブラブしているので、ブラブをお互いに読むことができます。

実際、blubにはマクロシステムがないため、blubの設計により、blubプログラマーは1つのblubファイルを読み取って理解することができます。

たとえば、CまたはC ++でプログラミングする場合（blubでプログラミングする場合でも、すべて多言語対応です）、新しいコード、または作業中のプロジェクトの標準であるオープンソースのものには、ほとんどblubスタイルを使用します。

1つの標準が必要です。私は、アプリケーションのさまざまなコーナーでさまざまな基準を見てきましたが、それらはすべて「自分たちのやり方で」やりたいと思っていたさまざまなリードを持っていました。おそらく「標準」の概念が誤解されていたのでしょう。非常に非常識です。そして、最悪の標準は一人で生成されます。その人が誰であるかは関係ありません。一人が一人で標準を開発すれば、悪い人であることはほぼ確実です。

それは人々を助けることができ、ツールを本当に助けることもできます：

あらゆる種類の自動コード書式設定を使用できるようにするには、使用するルールを標準化する必要があります。そうしないと、意味のない書式設定の変更が頻繁に発生し、差分が乱雑になります。

静的分析ツールのデフォルトのルールセットは、特定の命名スタイルをチェックする可能性があります。おそらく、すべてのラウンドを簡単に準拠させることができ、その後、多くの新しいルールを作成できます。（ルールを完全にオフにする場合を除き）

最後に、チーム外の誰かと相談する必要があるものをすべて標準化するとよいでしょう。すなわち、おそらくあなたの会社の法務チームを過ぎて書き込むすべての新しいファイルを実行したくないので、ヘッダーに標準の著作権表示が必要です。また、パブリックAPIの名前を最初に正しく取得する必要があります