アンクルボブは、コーディング基準を回避できるのであれば書き留めるべきではないと示唆しているのはなぜですか？
私が この質問を読んでいる の間、トップ投票の回答は引用 コーディング標準に関するボブおじさん でしたが、私はこのヒントに混乱していました。
- 回避できる場合は、書き留めないでください。むしろ、コードは標準が取り込まれる方法であるとしましょう。
これは頭の中で跳ねましたが、固執する場所が見つかりませんでした。新しい人がチームに参加したり、コーディング標準が変更されたりした場合、情報の混乱はありませんか？
コーディング標準を書き留めるべきではないのはなぜですか？
いくつかの理由があります。
- 誰もドキュメントを読みません。
- たとえドキュメントを読んだとしても、誰もドキュメントをフォローしません。
- たとえドキュメントを読んでそれに従ったとしても、誰もドキュメントを更新しません。
- 実践のリストを書くことは、文化を作ることよりもはるかに効果的ではありません。
コーディング標準は、人々が何をすべきかすべきではなく、実際にが何をすべきかについてのものです。人々が標準から逸脱するとき、これはコードレビュープロセスおよび/または自動化されたツールを通して拾い上げられ、変更されるべきです。
コーディング標準の要点は、私たちの生活をより簡単にすることです。重要なものから必要なものを除外できるように、これらは私たちの脳への近道です。これを文書化するよりも、それを実施するためのレビュー文化を作成する方がはるかに優れています。
別の解釈があります。ボブおじさんが意味したとは思いませんが、検討する価値はあります。
ドキュメント内のコーディング標準をキャプチャしないでください。それをコードでキャプチャします標準が満たされていることを確認する自動プロセスを使用することにより。
文書を参照する人に依存しないでください。同時に、既存のコードを解釈して、規則と偶然の一致を識別する人に依存しないでください。
Checkstyleなどをコミットビルドに組み込みます。これにより、フォーマットや命名の標準などの基本的なルールを適用でき、スタイルを検討するのに精神的な労力を費やすのではなく、すべてが少なくとも完全であることが保証されているダムプロセスにオフロードできます。
それが重要な場合は、それが何であるかを厳密に定義し、それが間違っている場合は失敗します。
人々は、紛争を解決するというコーディング標準文書の真の目的を見落とします。
コーディング標準の決定のほとんどは、読みやすさと生産性にごくわずかな影響しか与えません。特に、言語に「通常」のスタイルを採用すると、言語設計者はこれが仕様の一部であることに気づき始めています（例：Go）。
それらは非常に些細なものであるため、議論は非常に熱くなり、際限なく実行され、生産性とチームの結束に実際の損害を与える可能性があります。または、2人以上のユーザーが好むスタイル間での無限の再フォーマットにより、変更履歴を不明瞭にすることができます。
文書化された標準を持つことは議論を終わらせます。管理者はそれを指摘し、不満を文書に向けることができます。あなたは一枚の紙で議論することができますが、それはあなたの言うことに耳を傾けるつもりはありません。
（参照 構造のない暴君 ）
コメントは嘘 だからです。
コーディング標準は、コードがどうあるべきかについての大きなコメントです。コード自体が真の究極の情報源です。この場合の真実はコードの動作ではなく、それが表現されるスタイルです。標準がまだコードに反映されていない場合、多くの作業が必要になります。
ボブおじさんは、コメントをプログラマーの個人的な失敗だと考えています。それは、プログラミング言語自体でコードフラグメントの目的を表現できなかったことを証明しているためです。同様に、標準ドキュメントは、コードベースで一貫したスタイルを表現することの失敗です。
新しいプログラマーは、複数章の標準文書を読むのに何日も費やすのではなく、コードを見るのに時間を費やすべきです（私はこれをしなければならなかった、ため息）。
標準ドキュメントはそれほど悪い考えではありませんが、私は標準ドキュメントの保守が誰かのフルタイムの仕事であるプログラミングショップで働いています。標準ドキュメントを保持する必要がある場合は、ページに保持してください。しかし、もしあなたがすでにコードを持っているなら、誰もが1日以内に同じ文書をまとめることができるべきではないでしょうか？
コード標準を持つことは重要です。それらが何であるかを指示する文書を持つことはそうではありません。
ボブおじさんは、なぜそれを避けることができるなら、コーディング標準を書き留めるべきではないと勧めているのですか？
しかし、彼の意見の背後にある理由を尋ねている場合、あなたは 彼がここに回答を投稿する （our意見が無関係である）場合にのみ回答を得ることができます。 。
コーディング標準を書き留めるべきではないのはなぜですか？
彼がrightであるかどうかを尋ねている場合：私が（今のところ）唯一の不人気な人になって、あなたがそれを避ける理由がないと言ってください。
それを書き留めます。しかし、私は私の理由を説明しようとします...
デービッドはコメントで、スティーブンの答えの主要なポイントは、writeドキュメントをすべきではない理由ではなく、どの形式であるのかということを示唆しました。ガイドラインがtoolsで形式化されている場合（手動のコードレビューではない）、私は同意する場合があります（法律が他に何かを要求していない場合）。残念ながら、ツールは特定のtranslation unitまたはpackageなどに制限されているため、すべてをチェックすることはできません（計算理論は私たちの友人ではありません）。あなたの好きな言語はboundaryを呼び出します。
しかしボブおじさんの言葉遣いは、彼がそれについて話していると私に思わさせません。
そのような上級専門家に反対することはできますか？私は、引用された投稿のほとんどすべての点でそうします（詳細については、この回答の後半も参照してください）。 whyを理解してみましょう（コーディングガイドラインがマイナーなフォーマットissuesだけではないことをすでに知っていると仮定します）。
- 一部の状況では、法律によってコーディング標準が要求されています。
- 私はドキュメントを読んでいて、私だけではないと確信しています。チームメンバーは時間の経過とともに変化する可能性があり、知識は5〜10年前のコードベースやチームメンバーの心の中に存在することはできません。組織は、内部ガイドラインに従わない人々を解雇する必要があります。
- コーディング標準は、いったんapprovedになったら、頻繁に変更されることはなく、変更したい場合はそれについて知りたいです。標準が変更された場合、すべてのコードが新しい標準に従っていないため、documentation（コード内）は古くなっています。再フォーマット/リファクタリングは遅いかもしれませんが、常にauthoritativeのガイドラインに従ってください。
- 10/20KのLOCを調べてrule（誤って理解しているかもしれませんが、BTW）を推定するよりも、5ページのドキュメントを読むことをお勧めします。
- 皮肉なことに、設計原則とコーディングスタイルについて多くの本を書いた人が、独自のガイドラインを書くべきではないと示唆しているのですが、コードの例をいくつか提出してくれたら、もっといいのではないでしょうか。いいえ、書かれたガイドラインは何をすべきかを説明するだけでなく、コードに欠けている他の2つのことも行います。何をすべきかとそれをしない理由です。
「無料の自己組織化プログラミング」は忍者16歳の男性には適していますが、組織には他の要件があります：
- コードの品質は、会社レベルで付与（および定義）する必要があります。これは、単一のチームが決定するものではありません。彼らは何が良いかを決定するスキルすら持っていないかもしれません（たとえば、MISRAをレビューするために必要なスキルをすべて持っている開発者、または単に各ルールunderstandを持っている開発者の数は？）
- メンバーは異なるチーム間で移動できます。全員が同じコーディング標準に従っている場合、統合はスムーズでエラーが発生しにくくなります。
- チームが自己組織化している場合、標準はチームメンバーが変わると時間とともに進化します。その場合、現在の受け入れられた標準に従わない巨大なコードベースができます。
people before processについて考えている場合は、TPSについて読むことをお勧めします。人間はリーンの中心的な部分ですが、手順は非常に形式化されています。
もちろん、チームが1つだけの小さな組織mayは、採用する基準をチームに決定させますが、それを書き留める必要があります。エリックリッパートの投稿は、Programmers.SEで読むことができます。彼は経験豊富な開発者であり、Microsoftで働いたときは、ガイドラインに準拠しなければならなかったことに同意します（wrong、該当なしまたはuseless彼に。）ジョンスキートはどうですか？ Googleのガイドラインはかなり厳しい（そして多くの人がそれに同意しない）が、彼はそのようなガイドラインを遵守しなければならない。彼らに無礼ですか？いいえ、おそらく彼らはそのようなガイドラインを定義して改善するために働いていました、会社は1人のメンバー（または1つのチーム）によって作られておらず、各チームは島ではありません。
例
- 実際のチームメンバーはよく理解していないため、C++では多重継承とネストされたクラスを使用しないことにしました。後で多重継承を使用したい人は、1M LOC全体を参照して、それが使用されたことがあるかどうかを確認する必要があります。設計上の決定が文書化されていない場合は、コードベース全体を調査してそれらを理解する必要があるため、これは悪いことです。それでも、それが使用されていない場合、それはコーディング標準に違反しているためか、それとも許可されていますか？しかし、多重継承が適している以前の状況はありませんでしたか？
- C＃では、オプションのパラメーターがC＃で使用できないときにコードベースが開始されたため、デフォルトのパラメーターを提供するためにオーバーロードされたメソッドがありました。次に、変更してそれらを使用し始めました（そのような関数を変更する必要があるたびに、古いコードをリファクタリングして使用します）。さらに後で、オプションのパラメーターが不適切であると判断し、それらの使用を避け始めました。ruleあなたのコードは何を教えていますか？standardが進化するのは悪いことですが、コードベースは進化するのが遅く、それがドキュメントである場合は問題があります。
- ジョンはチームAからチームBに移動しました。ジョンは新しい標準をlearnする必要があります。学習中、彼はおそらくさらに微妙なバグを導入するでしょう（または、運が良ければ、既存のコードを理解してコードレビューを長くするために長い時間かかります）。
- チームAは、以前はチームBが所有していたコードベースに移行します。コードベースはまったく異なります。リライト？適応する？混合？それらのすべては同様に悪いです。
ボブおじさん
最初の数回の繰り返しで進化させます。
standardがなく、組織がbuildにタスクを割り当てない限り、真です。
会社固有ではなくチーム固有にする。
いいえ、上記で説明したすべての理由によります。コードのフォーマッティングだけを形式化すると考えていても（形式化したほうがよいとはいえ、最も役に立たないものです）、フォーマットに関する無限の（そして役に立たない）戦争の記憶があります。何度も何度も住みたいと思わないで、一度だけ設定して。
回避できる場合は、書き留めないでください。むしろ、コードが標準を取り込む方法であるとしましょう。
いいえ、上記のすべての理由により（もちろん、ガイドラインが変更されたときにすべてのコードを一度にリファクタリングしない限り）。コードをそのままにしますか？currentガイドラインを理解するためにコードベースをどのように検査しますか？ファイルageで検索し、コーディングスタイルをソースファイルの経過時間に適合させますか？
良いデザインを立法化しないでください。 （例：gotoを使わないように言わないでください）
確かに、ガイドラインは短くする必要があります。明白な繰り返しはしないでください。
標準はコミュニケーションに関するものであり、それ以外は何もないことを誰もが知っていることを確認してください。
だけでなく、minor詳細についてのみ基準を設定する場合を除き、優れた基準はqualityについてです。
最初の数回の反復の後、チームをまとめて決定します。
最初のポイントを見て、コーディング標準は通常、開発と改良に何年もかかったプロセスであることを忘れないでください。本当に？あるシニアメンバー（もしあれば）のメンバーの記憶に頼りたいですか？
3つのメモ：
- 私の意見では、いくつかの言語の欠点は他の言語よりも深刻です。たとえば、C++では、Javaよりも企業レベルの標準がさらに必要です。
- この推論mayは完全には適用されません（ボブおじさんの理由はextremeより少ない場合があります）。チーム。
- あなたは（チームとして）採用され、1つの新しいプロジェクトで一人で作業することになりますが、それを忘れて次へ進みます。この場合、youは気にしないかもしれません（ただし、雇用主は...）
- コーディング標準が有用であるためには、実質の問題について話してはなりません。スタイルの問題のみ。恣意的で曖昧なものだけを指定する必要があります。例えばブレースの配置、インデントの深さ、スペースとタブ、命名規則など。
- スタイルの問題はローカルではなく、グローバルです。各チームは、自分の仕事と個性に合わせた独自の独特のスタイルを採用する必要があります。これにより、規格がシンプルで軽量に保たれます。企業の標準は、考えられるすべての考慮事項、構成、および例外で過負荷になっています。
- チーム内で、別のコーディングスタイルドキュメントを作成する唯一の理由は、チームが作成したコードが標準を満たしていない場合です。その場合、標準はありません。効果を上げるには、規格をコード自体で表現する必要があります。その場合、個別のドキュメントは必要ありません。
- レガシーシステムでは、チームとスタイルは時間とともに変化します。それには何も問題はありません。古いコードは古いスタイルになります。新しいコードは新しいスタイルになります。チームは、スタイルとその年齢を認識する必要があります。新しいコードが書かれるときはいつでも、コードのどこに配置されていても、新しいスタイルにする必要があります。
コーディング標準を書き留めるべきではないのはなぜですか？
これには多くの理由があります。考慮事項は次のとおりです。
チーム全体でコード標準の確認、議論、文書化、改訂などに多くの時間を費やすためだけに、コード標準を「学習」するのに費やしている時間はどれくらいですか。これは、「従業員ハンドブック」について常に話し合うようなものです。チームミーティングの議題には、どれくらいの頻度で参加しますか？
プロジェクトが資金調達/棚上げ/その他されたとき。そうなると、通常残っている少数の人々は、標準に準拠し続けることができません（または、おそらく読んでさえいないでしょう）。次に知っているのは、「コードをクリーンに保つ」ためのすべての努力がとにかく無駄だったということです。
プロジェクトが停滞したり、新しいリードがもたらされたりした場合、その人は以前のルールを完全に無視し、新しい方法を実行したいと考える可能性が非常に高くなります。繰り返しになりますが、標準を体系化することによって何が得られましたか？
＃6を必ずお読みください。
最初の数回の反復の後、チームをまとめて決定します。
つまり、プロジェクトを開始するときは、しばらくフローを実行するだけです。次に、現在のチームが使用しているコーディング標準の一般的なルールについて話し合い、基本的にはそれらに従います。そうすることで、製品の改善にかかる労力を最大化し、実行可能コードの取得に費やされた「構文糖」を記述、レビュー、文書化するために必要な労力を最小化します。
コーディング標準から大きなメリットを得ているチームはほとんどありません。通常、「読みやすさ」は曖昧すぎます。ほとんどの開発者は、間隔、改行などに関するexactルールの恩恵はあまり受けませんが、常に回避できます少なくともいくつかのルールを持つことにより、開発者を煩わしい。
私が十分に明確に述べられていないと思うもう1つの答えは、人々がルールを盲目的に守らないことも意味するということです。それは、人々がそれを正当化するために書き留められているという事実に頼るのではなく、彼らの設計決定とコーディング規約のための実際の正当化を考え出さなければならないことを意味します。
最初に、私の知る限り、ボブおじさんはJava人、これは彼の言うことを理解するために非常に重要です。
JavaまたはC＃チームで作業しているときに、現在のコードが経験豊富な開発者によって記述されている場合、コーディングスタイルを選択してそれを維持するのは簡単です。私がそうするつもりがない場合、おそらく私はその仕事に適した人物ではなかったかもしれません...コードレビューまたはペアプログラミングがなければ、私をピックアップしますスタイルに固執しないでください。その場合、メンバーフィールドに名前を付ける方法よりも大きな問題が発生します。
JavaとC＃の両方、および最新のほとんどの言語とともに、プログラマーが陥る「単純な」トラップがほとんどないように定義されています。
しかし、プログラミングを始めたとき、私はC（およびその後のC++）を使用していました。 Cでは次のようなコードを書くことができます
if (a = 3);
{
/* spend a long time debugging this */
}
コンパイラーはエラーを出さず、多くのコードを読み取るときにそれを見つけるのは困難です。ただし、次のように記述した場合：
if (3 = a)
{
/* looks odd, but makes sense */
}
コンパイラーはエラーを出し、コードを3 == aに変更するのは簡単です。同様に、コーディング標準が=をif条件または「空のifステートメント」内で使用することを許可しない場合、コードチェッカーをビルドの一部として使用できますこのエラーを追跡するシステム。
C/C++から離れると、コーディング標準に関する私の見方は大きく変わりました。以前は、厳密に施行され、多くのページが長いコーディング標準が好きでした。使用しているツールをリストするだけで、いくつかの命名規則について元のチームメンバー間で非公式の合意を得る必要があると思います。私たちは、C/C++でアプリケーションを作成する30人を超える開発者のチームの世界に住んでいません...
私がJScriptを好きにならなかった理由があり、TypeScriptは何年もの間Web開発に起こる最良のことだと思います。 HTML/CSS/JScriptなどの設計上の欠陥により、Web UI開発者はまだコーディング標準を必要としていると思います
ソースを自己文書化するコーディング標準にすることは、2つのことを意味します。
- 人々は熟練した貢献者になるために、コードベースを調べ、それをレビューする必要があります。これは非常に重要です。コーディングガイドラインを読むことは、コードベースに飛び込むのに比べて時間の無駄です。
- 小さな違いは重要ではないと認めています。基本原則に同意して理解することが重要です。 l'art pour l'artとして一貫したスタイルを維持することは追求されていません。それは創造的ではないニッピッカーが他の人々を煩わせて気を散らすことを許しません。チーム内のコードを介してコミュニケーションを促進することです。
頻繁に更新され、よく書かれたコード標準ドキュメントは非常に便利ですが、通常はそうではありません。優れた標準文書を作成することは非常に難しく、最新に保つことがさらに難しいため、標準文書は会社が使用する実際のコーディング標準を反映していません。
貧弱で誤解を招くコーディング標準のドキュメントを用意する代わりに、何も持たず、コード自体がそれらの標準を表すようにする方がよいでしょう。どちらの方法でも、最も重要な部分はコードに標準を適用することであり、これには単なるドキュメント以上のものが必要です。動機、プロセス、トレーニング、ツールなどがはるかに重要です。
十分に明確に述べられていない非常に重要なことは、コーディング標準が言語のようなものであるということです：それらは進化します。書かれたコーディング標準はこの点で邪魔をし、もしそうでなければ、それは絶えず時代遅れで役に立たないものです。
釘付けにされたコーディング標準がないことはそれほど悪いことではありません。チェックイン時にピアレビューを行う場合、コーディング標準に準拠していない何かがリポジトリに入ると、2人がそれについて考え、このバリエーションの利点がコードの他の部分との不一致に勝るということを意味します。
書き留められた規格がないと、企業のチームが何かを試したい、または別の規格に実用的なアプリケーションがあるために、新しいプロジェクトのコーディング規格の新しいバリエーションを試すことを妨げる赤いテープも削除されます彼らが使用する自動化ツールの一部。
標準を書き留めると、本来意図されていたよりも多くの柔軟性が失われる傾向がありますが、他の作業に費やされる可能性のあるかなりの時間もかかります。コーディング標準を書き留めるべきではないと言っているのではありません。特に、異なる場所で作業しているチームが同じコードベースで作業している場合は、書かれた標準には確かに利点があります。
強く関連： コーディング標準の進化、それらにどのように対処しますか？
*チェックイン時にピアレビューを行っている人が考えていない場合、問題はコーディング標準だけではありません。
それらを変更することは大きなハードルになり、人々は頭脳を関与させて正しいことをするのではなく、法の手紙を安全に守ります。
標準の一部が役に立たず、コードを悪化させる日が来るでしょう。標準が書き留められて安全であり、ルールに従う必要があるため、一部の人々は標準に準拠します。標準に準拠したコードではなく、優れたコードを記述したい人はイライラして怒ります。議論や意見の不一致があるでしょうが、基準が書かれていなければ、調査と議論が行われるでしょう。
ここの多くの投稿は、コーディング標準とスタイルガイドを混同していると思います。
異なるチームによって開発されたモジュールが同じコンパイラオプションを持ち、ABIがインデントされているスペースの数とは異なる種類のものであることを確認します。
#includeファイルを構造化し、ヘッダーファイルのグローバル名前空間を汚染しない適切な方法のようなものすべきを文書化して、最初のコーディングやコードレビューの際にチェックリストとして使用できるようにします。
特に、「XXXはYYYとの互換性の問題を引き起こすため、使用しないでください」はではないので、他のコードの例では見られないものです。したがって、標準を取得する方法をコードにする一部の種類の標準では不明確または完全に欠落している可能性があるため、これは普遍的な計画にはなりません。
例外を使用しない、または特定の組み込みシステムでnewを使用しないなど、非常に広範で重要なものcannot「情報は文化的な（唯一の）」矛盾であるので、単に共通の文化の知識に任せるこれらの組み込みシステムの開発者が使用している、ISO-9000などの製造規格の基本原則（自動車アプリケーションなど）。これらの重要なものは文書化され、承認され、正式な方法で提出されなければなりません。
ただし、これはcodingに適用され、styleには適用されません。
CおよびC++の発明者は、例として、小文字の名前の使用とCaMelCaSeの使用を示しています。それでは、なぜそれほど多くの開発者が泉からの暗黙の例に従わないのですか？標準ライブラリと標準的な教材のスタイルは、従うべき暗黙のスタイルではないでしょうか？
一方、人々doは、マクロパラメータの__Ugly名の使用やインクルードファイル非-繰り返しパターン。
だから、ものを持っていることは重要なスタイルとは見なされないことが多く、逆に例を持っていると、プロジェクトコードでしてはいけないことを明確にできない場合があります。どちらも、「スタイル」（またはコーディング規約）は暗黙的に残すのが最善であるという論文の反例です。