私のチームは、独自の基準として、よく評価されている一般的なコーディング標準を使用する必要がありますか？

私が参加している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」の回答を見て、標準があることのいくつかの利点を確認してください。一貫性と変更の基礎を持つことは、あなたの観点から重要です。

また、「コーディング標準の処理（私は上司ではありません）」も参照してください。これは、標準を選択する際にチームが考慮する必要があるチームのダイナミクスの一部になるためです。チームはコーディング標準を所有する必要があるため、誰もが各自がコーディングする方法に課す制限に喜んで従います。

この質問にリンクしましたが、上位の回答と、要件が設定されている理由を理解することに焦点を当てることを指摘する価値があります。外部標準を使用する場合、チームがこれらすべての要件の背後にある基礎を理解するのは困難になります。しかし、チームが最初に何かを必要としていたという理由だけでそれらが存在することを受け入れる場合、その外部標準をチームにとってより効果的なものに変更することは簡単です。

標準を設定すると、IDE（この場合はEclipse）で使用するフォーマットルールを設定できます。「コードの強制的な再フォーマットのメリットとデメリット」は、チームの全員が作業しているコードとの一貫性があるというメリットをもたらし、他のプロジェクトから借りることができるスニペットを再フォーマットする機能を提供します。外部標準を使用することの追加のボーナスは、IDEのコードフォーマット部分にすでに事前に入力されている可能性があることです。

チームの誰かが標準の特定の部分について不平を言う可能性が高く、ベースとして外部標準を使用したという事実のせいです。彼らに読んでもらいます：
- 私は私たちのコーディング標準の1つを嫌い、それは私を狂気にさせます、それをどのように処理するのですか？
- レガシーコードを渡されたときに、独自のコーディングバイアスをどのように克服しますか？
そして、それがどこから来たのかに関わらず、規格内の何かについて不満を抱いていた可能性が高いことに気づきます。私が取り組んできたチームの数全体で、私は誰もがa）普遍的に好きで、b）標準のすべての部分に同意した標準をまだ見ていません。これらの懸念に対処する方法を確認するには、初期のリンクの一部を参照してください。

補遺、あなたはあなたが「どちらを使うべきか」について尋ねました。具体的な答えはしませんが、どのような答えも潜在的には炎上戦争の火付け役となっています。ただし、IDE（Eclipse）を見て、標準構成として提供されているオプションを確認することもできます。また、少し検索して、IDEにプラグインするプロジェクトがあるかどうかを確認し、追加の標準オプションを選択できるようにします。正しいか間違っているかを問わず、これらの標準は既に作成されており、すべての人のために構成する際のチームの作業を節約できます。

私はpythonから始めます。Pythonには、ほとんどすべてのPythonプログラマが従うコーディングガイドラインがあります。これらはPEP8と呼ばれる公式ドキュメントの一部です。

C / C ++は歴史的な理由から大きな混乱ですが、Pythonはそうではないので、一貫性を保つためにC / C ++でもPythonの命名規則に従うことをお勧めします。

C ++の場合、共通のイディオムに同意し、すべての人が合理的な最新のC ++スタイルを、命名規則に関する戦争よりも理解するようにすることが実際に重要です。C ++コーディング標準から始めて、オンラインリソースからC ++ FAQを必ずお読みください。

コーディング標準とコーディングスタイル標準を区別せずにこのトピックについて話し合うことはできません。

コーディング標準は、使用を許可されている言語メカニズム、使用を許可されていない言語メカニズム、およびそれらの使用方法を定義する一連のルールです。言い換えると、コーディング標準が特定の非標準の拡張機能に対応している場合は、使用する言語のサブセットやスーパーセットを定義します。

コーディングスタイル標準は、ブレースとスペースの配置場所、識別子の命名方法、コメントの配置方法など、表面的な問題のみに関係しています。

これら2つの異なるものは、同じドキュメント内にある場合があります。ただし、最も深刻なコーディング標準はスタイルに関係していません。以下に推奨するものは関係ありません。最も可能性が高いのは、コーディングスタイルが非常に主観的であり、意見が衝突したときに多くの摩擦を引き起こすためです。

C / C ++の場合、最も評判の高いコーディング標準はMISRAのコーディング標準です。それらは安全/ミッションクリティカルなアプリケーション向けに主に設計されていますが、プログラムをより安全にする鍵はバグを削除して回避することであるため、MISRA標準はバグが望ましくないすべてのプログラミングブランチに適用されます。

CERTの標準もかなりよく知られており、（安全ではなく）デスクトッププログラミングとソフトウェアセキュリティに偏っています。CERTにはC、C ++、Java、Perlの標準があり、標準は無料です。

まず、Webにあるランダムなガレージ標準ではなく、MISRAとCERTを見てみましょう。

独自の基準として既存の標準を使用すると、いくつかの利点があります。コードはおそらく外部コードに似ているため、コードの読み取り/統合が容易になります。さらに、適切な標準を選択すると、特定のルールを決定する十分な理由がある専門家によって検討されます。チームの誰も特に標準に関連付けられていない限り、既存の標準を独自の標準として使用しない理由はほとんどありません。

使用するコーディング標準がわからない場合は、いくつかの明らかな理想的な最初の選択肢があります。順不同：
1. IDEですでにサポートされている標準。これはおそらく設定可能です。
2.コンパイラの作成者が使用/推奨している標準。
3.プライマリフレームワーク（存在する場合）の作成者が使用/推奨する標準。
4.プログラミング言語の作成者/設計者が使用/推奨している標準。
5.非常に大規模な会社で使用/推奨されている標準。

自分の標準の基礎として使用している標準について、技術的な専門知識を持つ人に読んでもらうことをお勧めします。多くの場合、優れた標準には、各ルールの正当性があり、ニーズに最も適合するように標準を変更するのに役立ちます。

標準は通常、通信と保守に役立ちます。私の意見では、特に小さなチームでは、いくつかのギブアンドテイクの対象となり、進化する必要があります。それらをガイドラインと呼ぶことは役立つかもしれません:-)

見てください、Googleのガイドラインにインスピレーションを得るために。

いいえ、私は気にしないだろう-私があなたのチームがそれらの標準が同様に使用された場所に移動した場合、唯一の利益はあなたが起こりたいことではないでしょう:)

標準は、コラボレーションを容易にするためにのみ存在するため、＃defineマクロが常に大文字であることがわかっている場合、コード内で大文字の識別子が表示されれば、そのマクロについて公平に理解できます。同様に、他の命名規則またはスタイル規則は、何を扱っているかを思い出させます。

ファイルの場所や名前などの標準の方が便利だと思います1。コードの標準（結局のところ、コードはすべての形とサイズで提供されるため、コードを読む必要があります）よりも、readme.txtが/ bin / doc / debugにあることがわかりません。 / release / documentsは本当の苦痛です（そのようなくだらないパスはそうですが、それは別の話です）。

自分自身で基準を上げて行くことをお勧めします。このようにして、あなたはすべて好きなものを手に入れるだけでなく、あなた、あなたのチーム、そしてあなたが行う仕事に間違いなくふさわしいものを手に入れます。whileループがどのように見えるかを気にしない、またはそのcaseステートメントを特定の方法でインデントする必要がある場合は、問題ありません。++演算子が禁止されていると判断した場合も同様です。すべてあなた自身の選択。

あなたはそれを簡単に見つけて更新できるようにする必要があります、多分ウィキ、またはテキストの説明から自動生成されたウェブページ、しかしそれ以外の場合-それのために行きます。標準は、優れたコードを書くよりも熱心に標準に従うことに興味がある一部の人々からの神話的な態度を持っています。標準のようではなく、必要な場所で役立つ独自の標準を作成してください。