私のチームは、独自の基準として、よく評価されている一般的なコーディング標準を使用する必要がありますか？
私が参加しているR＆Dチームは、コーディング標準を採用することを決定しました。私たちは最近結成したばかりであり、コードや共通のコーディング時間が少なすぎて、チームで有機的に開発されたものや、独自のコードの良い例などに基づいて標準/規約のドキュメントを作成できません。
今、私たち一人一人が過去の職場での経験を持っていますが、「ここで行うこの種の仕事にふさわしいとわかった、この包括的なドキュメントをここで採用しましょう」と言っている人はいません（*）。さらに、一部の私（自分自身を含む）は、公式のコーディング標準がない場所、または別の設定で別の言語で作成した経験しかありません（より研究指向の開発作業とは対照的に、毎週リリースされる高圧の本番環境）。
したがって、私が考えていたオプションの1つは、比較的よく知られていて評判の高いドキュメントを取得し、気にしていない/気にしていないものを取り除き、好みに基づいていくつかの変更を加えることです。
これは一般的な方法ですか？これは良いアイデアだと思いますか？もしそうなら、合理的な「ベースライン」コーディング標準は何でしょうか（どちらが最善か教えてください、ここで宗教的対立を始めたくありません。包括的または「中立」に基づいて構築できるものを指摘してください） 。）
注：
- C、C++、OpenCL、CUDA、Pythonで動作することを期待しています。
- 私たちは4人+マネージャーのチームで、1年程度で5〜6人に成長すると予想されています。
- 私たちの会社では、チームはほとんど完全に自律的であり、通常はまったく相互作用しません（お互いのコードを使用することによってさえも-作業は完全に異なるプロジェクトにあります）。そう-全社的な考慮事項はありません。
- ツールに関しては、現時点で Eclipse を使用することがわかっているため、コードフォーマッタは少なくとも1つのツールになります。 Ctrl + Shift + Fは長い間私の友人です
- 私がJavaを書くとき、私は Blochの効果的なJava にできる限り厳密に従うことを採用しました。さて、それは完全なコーディング標準ではありませんが、コーディング標準のレンガ、セメント、モルタルを呼び出すことができます。私はそのようなものを「ミックス」の一部として含める可能性があると考えていました（Javaは実行しないことに注意してください）。
- 言葉の広い意味でのコーディング標準を意味します。 このP.SEの質問への回答で行われた提案を採用する 。
- C++コーディング標準ドキュメントの 大きなリストを見つけました ;多分私はそのベースラインを採掘する必要があります。
- （*）それはまったく真実ではありませんが、私はこの質問をあまりにも多くの詳細で複雑にしたくありません。
別の言い方をすると、見つけた外部標準を借用して、チームのコーディング標準をすぐに始める必要があるかどうかを尋ねています。チームの誰もがそれらの標準がどうあるべきかについて（まだ）超強力な意見を持っているようには思えません。
正解は、答えはイエスです。
外部から調達された標準は、何よりも優れています。 " https://softwareengineering.stackexchange.com/q/84203/53019 "の回答を参照して、標準を持つことのいくつかの利点を確認してください。一貫性と変更の基礎を持つことは、あなたの観点から重要です。
また、 " Handing Coding Standards at Work（I'm'n's boss） "も参照してください。これは、チームが標準を選択するときに検討する必要があるチームダイナミクスの一部になるためです。する必要があります。チームはコーディング標準を所有する必要があるため、誰もが各自がコーディングする方法に課す制限に喜んで従います。
あなたはこの質問にリンクしましたが、 最高の回答 と、要件が設定されている理由を理解することに焦点を当てていることを指摘する価値があります。外部標準を使用する場合、チームがこれらすべての要件の背後にある基礎を理解するのは困難になります。しかし、チームが最初に何かを必要としていたためにそれらが存在することを受け入れる場合、その外部標準をチームにとってより効果的なものに変更することは簡単です。
標準を設定すると、IDE（この場合はEclipse）で使用するフォーマットルールを設定できます。 " 強制コード再フォーマットの利点と欠点 "は、チームの全員が作業中のコードとの一貫性を保つための利点になり、他から借りることができるスニペットを再フォーマットする機能を提供しますプロジェクト。外部標準を使用することの追加のボーナスは、IDEのコードフォーマット部分にすでに事前に入力されている可能性があることです。
チームの誰かが標準の特定の部分について文句を言う可能性が高く、ベースとして外部標準を使用したという事実のせいです。それらを読んでもらいます：
- 私はコーディング標準の1つが嫌いで、それが原因で狂ってしまい、どう処理するか？
- レガシーコードを渡したときに、独自のコーディングバイアスをどのように克服しますか？
そして、それがどこから来たのかに関わらず、規格内の何かについて不満を抱いていた可能性が高いことに気づきます。私が取り組んできたチームの数全体で、私は誰もがa）普遍的に好きであり、b）標準のすべての部分に同意した標準をまだ見ていません。これらの懸念に対処する方法を確認するには、初期のリンクの一部を参照してください。
補遺、あなたはあなたが「どちらを使うべきか」について尋ねました。具体的な回答はしませんが、どのような答えでも、潜在的な意見の火花戦争が繰り広げられる可能性があります。ただし、IDE（Eclipse）を見て、標準構成として提供されるオプションを確認することもできます。私も少し検索して、IDEにプラグインするプロジェクトがあるかどうかを確認し、そこから選択する追加の標準オプションを提供します。正しいか間違っているかを問わず、これらの標準は既に作成されており、すべての人のために構成する際にチームの作業を減らすことができます。
私はpythonから始めます。 Pythonにはコーディングガイドラインがあり、ほぼすべてのpythonプログラマーが従います。これらは PEP8 と呼ばれる公式ドキュメントの一部です。
C/C++は歴史的な理由で大きな混乱ですが、pythonはそうではないので、C/C++でもpython命名規則に従うことをお勧めします一貫性のために。
さて、C++の場合、共通のイディオムに同意し、命名規則に関する戦争よりもすべての人が合理的な最新のC++スタイルを理解するようにすることが実際に重要です。 C++ Coding Standards から始めて、オンラインリソースから C++ FAQ を必ずお読みください。
コーディング標準とコーディングスタイル標準を区別せずにこのトピックを議論することさえできません。
コーディング標準は、使用を許可されている言語メカニズム、使用を許可されていない言語メカニズム、およびそれらの使用方法を定義する一連のルールです。言い換えれば、コーディング標準が特定の非標準の拡張機能に対応している場合は、使用する言語のサブセットやスーパーセットを定義します。
コーディングスタイル標準は、ブレースとスペースの配置場所、識別子の命名方法、コメントの配置方法など、表面的な問題のみに関係しています。
これら2つの異なるものは、同じドキュメント内にある場合があります。ただし、最も深刻なコーディング標準はスタイルに関係していません。以下に推奨するものは関係ありません。最も可能性が高いのは、コーディングスタイルが非常に主観的であり、意見が衝突したときに多くの摩擦を引き起こすためです。
C/C++の場合、最も評判の高いコーディング標準は [〜＃〜] misra [〜＃〜] のコーディング標準です。これらは主に安全/ミッションクリティカルなアプリケーション向けに設計されていますが、プログラムをより安全にするための鍵はバグを削除して回避することであるため、MISRA標準はバグが望ましくないすべてのプログラミングブランチに適用されます。
[〜＃〜] cert [〜＃〜] の標準もかなりよく知られており、（安全ではなく）デスクトッププログラミングとソフトウェアセキュリティに偏っています。 CERTには、C、C++、JavaおよびPerlの標準があり、標準は無料です。
まず、Webにあるランダムなガレージ標準ではなく、MISRAとCERTを見ていきます。
独自の基準として既存の標準を使用すると、いくつかの利点があります。あなたのコードはおそらく外部コードにより類似しており、コードを読みやすく/統合しやすくしています。さらに、適切な標準を選択すると、特定のルールを決定する十分な理由がある専門家によって検討されます。チームの誰も特に標準に縛られていない限り、既存の標準を独自の標準として使用しない理由はほとんどありません。
使用するコーディング標準がわからない場合は、いくつかの明確な理想的な最初の選択肢があります。順不同：
1。 IDEですでにサポートされている標準。これはおそらく設定可能です。
2。コンパイラの作成者が使用/推奨する標準。
3。 （存在する場合）プライマリフレームワークの作成者が使用/推奨する標準。
4。プログラミング言語の作成者/設計者が使用/推奨している標準。
5。非常に大規模な会社で使用または推奨されている標準。
自分の標準の基礎として使用している標準について、技術的な専門知識を持つ人に読んでもらうことをお勧めします。多くの場合、適切な標準には、各ルールの正当性があり、ニーズに最も適合するように標準を変更するのに役立ちます。
標準は通常、通信と保守に役立ちます。私の意見では、特に小規模なチームでは、いくつかのギブアンドテイクの対象となり、進化する必要があります。それらをガイドラインと呼ぶことは役立つかもしれません:-)
Googleガイドライン を参考にしてください。