ボブおじさんが、コーディング標準を避けることができれば書き留めてはならないと提案するのはなぜですか？

私がこの質問を読んでいる間、トップ投票の回答はコーディング基準についてボブおじさんを引用しましたが、私はこのヒントに混乱しました：

3. 回避できる場合は書き留めないでください。むしろ、コードを標準の取得方法にしてください。

これは私の脳内で跳ね返りましたが、固執する場所を見つけることができませんでした。新しい人がチームに参加した場合、またはコーディング標準が変更された場合、情報の混乱はありませんか？

コーディング標準を書き留めてはいけないのはなぜですか？

いくつかの理由があります。

1. 誰もドキュメントを読みません。
2. たとえ彼らがそれを読んだとしても、誰もドキュメントを追っていません。
3. ドキュメントを読んで従ったとしても、誰もドキュメントを更新しません。
4. 実践のリストを書くことは、文化を作ることよりもはるかに効果的ではありません。

コーディング標準は、人々が何をすべきかについてではなく、実際に何をすべきかについてです。人々が標準から逸脱する場合、コードレビュープロセスおよび/または自動化ツールを使用してこれを拾い上げ、変更する必要があります。

コーディング標準のポイントは、私たちの生活を楽にすることです。重要なものから必要なものを除外できるように、それらは私たちの脳への近道です。これを強制するためにレビューの文化を作成する方が、文書で形式化するよりもはるかに優れています。

別の解釈があります。私はそれがボブおじさんの意図したことだとは思いませんが、検討する価値はあります。

ドキュメント内のコーディング標準をキャプチャしないでください。標準が満たされていることを確認する自動プロセスを使用して、コードでキャプチャします。

文書を参照する人に頼るのではなく、同時に、すでに存在するコードを解釈し、慣習と偶然の一致を識別する人に頼らないでください。

Checkstyleのようなものをコミットビルドに組み込みます。これにより、フォーマットや命名基準などの基本的なルールを実施でき、スタイルを検討する際に精神的な労力を費やすのではなく、少なくとも徹底的に保証された愚かなプロセスにすべてをオフロードできます。

それが重要な場合は、必要なものを厳密に定義し、間違っている場合は失敗します。

人々は、紛争を解決することであるコーディング標準文書の本当の目的を見過ごしています。

コーディング標準の決定のほとんどは、読みやすさと生産性にほとんど影響しません。特に、言語に「通常の」スタイルを採用し、言語設計者がこれが仕様の一部であることを認識し始めている場合（例：Go）。

それらは非常に簡単なので、議論は本当に熱くなり、無限に続き、生産性とチームの結束に本当のダメージを与えます。または、2人以上の好みのスタイルを無限に再フォーマットして、変更履歴を不明瞭にすることができます。

文書化された標準を持つことで議論が終わります。管理者はそれを指摘し、ドキュメントに対する不満をそらすことができます。あなたは一枚の紙で議論することができますが、それはあなたに耳を傾けるつもりはありません。

（無構造の圧制も参照）

ので、コメントは嘘です。

コーディング標準は、コードがどうあるべきかについての大きな大きなコメントです。コード自体が究極の真実の源です。この場合の真実はコードの振る舞いではなく、それが表現されているスタイルです。もしあなたの標準があなたのコードにまだ反映されていないなら、あなたは先に多くの仕事を持っています。

ボブおじさんは、コメントをプログラマーの個人的な失敗と見なします。これは、プログラミング言語自体でコードフラグメントの目的を表現できなかったことを証明しているからです。同様に、標準文書は、コードベースで一貫したスタイルを表現できないことです。

新しいプログラマーは、複数の章からなる標準ドキュメントを読むのに何日も費やすのではなく、コードを見ることに時間を費やすべきです（これはため息がつきました）。

標準文書はそれほど悪い考えではありませんが、私は標準文書の保守が誰かのフルタイムの仕事であるプログラミングショップにいました。標準文書を保管する必要がある場合は、ページに保管してください。しかし、既にコードを持っている場合、誰もが1日以内に同じドキュメントをまとめることができるはずではありませんか？

コード標準を持つことが重要です。それらが何であるかを指示する文書を持つことはそうではありません。

ボブおじさんが、コーディング標準を避けることができれば書き留めてはならないと提案するのはなぜですか？

あなたが彼の意見の背後にある理由を尋ねているなら、あなたは彼がここに答えを投稿する場合にのみ答えがあるかもしれません（私たちの意見はただ無関係です）...

コーディング標準を書き留めてはいけないのはなぜですか？

あなたが彼がそれについて正しいかどうか尋ねているなら、あなたがそれを避ける理由がないと言うために、私が（これまでのところ）不人気なものにしてください。

それを書き留めます。しかし、私は私の理由を説明しようとします...

Davidはコメントで、Stephenの答えの要点は、文書を書くべきではなく、どのような形式で書かれるべきなのかということです。ガイドラインがツールで公式化された場合（単なるコードのレビューではなく）、同意する場合があります（法律が他に何かを必要としない場合）。残念なことに、ツールは特定の翻訳単位またはパッケージ、またはあなたの好きな言語が境界と呼ぶものに限定されているため、すべてを頻繁にチェックできないことに注意してください（計算の理論は私たちの友人ではありません）。

しかし、ボブおじさんの言葉遣いは、彼がそれについて話しているとは思わない。

そのような上級の専門家に反対することはできますか？私は、引用された投稿のほぼすべてのポイントについて行います（詳細については、この回答の後半も参照してください）。その理由を理解してみましょう（コーディングガイドラインが単なる小さなフォーマットの問題ではないことを既に知っていると仮定します）。

• 状況によっては、法律によりコーディング標準が必要になります。
• 私はドキュメントを読んでいますが、私は一人ではないはずです。チームメンバーは時間とともに変化する可能性があります。知識は5〜10年前のコードベースやチームメンバーの頭の中にはありません。組織は、内部ガイドラインに従わない人を解雇する必要があります。
• コーディング標準は、いったん承認されると、頻繁に変更されることはなく、もしそうなら、それについて知りたいと思うでしょう。すべてのコードが新しい標準に従っていないため、標準が変更された場合、ドキュメント（コード内）は古くなっています。再フォーマット/リファクタリングは遅くなる場合がありますが、必ず従うべき正式なガイドラインが書かれています。
• 10 / 20K LOCを調べてルール（間違って理解しているかもしれませんが、BTW）を推定するよりも、5ページのドキュメントを読む方が良いでしょう。
• 皮肉なことに、デザインの原則とコーディングスタイルについて多くの本を書いた人が、独自のガイドラインを書くべきではないことを提案しているのです。いいえ、文書化されたガイドラインは、何をすべきかを伝えるだけでなく、コードには欠けている他の2つのことも行うからです。

「無料の自己組織化プログラミング」は16歳の忍者には適していますが、組織には他の要件があります。

• コードの品質は、企業レベルで付与（および定義）する必要があります。単一のチームが決定するものではありません。何が優れているかを判断するスキルさえ持っていない場合があります（たとえば、MISRAを確認したり、各ルールを理解するために必要なすべてのスキルを持っている開発者はどれくらいいますか？）
• メンバーは異なるチームに移動する可能性があります。全員が同じコーディング標準に従うと、統合がスムーズになり、エラーが発生しにくくなります。
• チームが自己組織化されている場合、チームメンバーが変更されると標準は時間とともに進化します。その場合、現在受け入れられている標準に準拠しない巨大なコードベースができます。

あなたがプロセスの前に人々について考えているなら、私はTPSについて読むだけを提案することができます：人間はリーンの中心的な部分ですが、手順は高度に形式化されています。

もちろん、チームが 1つだけの小さな組織では、採用する標準をチームに決定させることができますが、それを書き留める必要があります。ここProgrammers.SEにあなたはエリックリペットによって記事を読むことがあります。私たちはすべての彼は経験豊富な開発者であることに同意したと、彼はマイクロソフトのために働いていたとき、彼は自分の書かれたガイドラインを遵守しなければならなかった（いくつかのルールがあることもあっても間違って、適用できないか、役に立ちませんジョン・スキートはどうですか？Googleのガイドラインは非常に厳密です（そして多くの人々はそれらに同意しません）が、彼はそのようなガイドラインに従う必要があります。それは彼らに無礼ですか？いいえ、彼らはおそらくそのようなガイドラインを定義および改善するために働いたでしょう。会社は1人のメンバー（または1つのチーム）によって作られたものではなく、各チームは島ではありません。

例

• 実際のチームメンバーはそれをよく理解していないため、C ++で多重継承とネストクラスを使用しないことにしました。後で複数の継承を使用する場合は、1M LOC全体を参照して、使用されたことがあるかどうかを確認する必要があります。設計上の決定が文書化されていない場合、コードベース全体を理解してそれらを理解する必要があるため、それは悪いことです。そしてそれでも、それが使用されていない場合、それはコーディング標準に違反しているためですか、それとも許可されていますが、多重継承が適切であった以前の状況はありませんでしたか？
• C＃では、オプションパラメーターがC＃で使用できないときにコードベースが開始されたため、デフォルトパラメーターを提供するオーバーロードメソッドがありました。その後、変更して、それらの使用を開始しました（そのような関数を変更するたびに使用するように古いコードをリファクタリングします）。後で、オプションのパラメーターが悪いと判断し、それらの使用を避け始めました。何のルール、コードがわかりますか？標準は進化しますが、コードベースの進化は遅く、ドキュメントの場合は問題が発生するため、これは悪いことです。
• ジョンはチームAからチームBに移動しました。ジョンは新しい標準を学ぶ必要があります。学習中に彼はおそらくより微妙なバグを導入します（または、幸運な場合は、既存のコードを理解し、コードレビューを長くするために長い時間をかけるだけです）。
• チームAは、チームBが以前所有していたコードベースに移行します。コーディングベースはまったく異なります。リライト？適応する？混合？それらはすべて同様に悪いです。

ボブおじさん

最初の数回の反復でそれらを進化させます。

確かに、標準がなく、組織があなたに標準を作成するタスクを割り当てた。

会社固有ではなく、チーム固有のものにしてください。

いいえ、上記のすべての理由によります。コードのフォーマットだけを形式化することを考えたとしても（形式化するのが最も有用ではないかもしれません）、フォーマットに関する無限の（そして役に立たない）戦争の記憶がまだあります。私はそれらを何度も繰り返して生きたくはありません。

回避できる場合は書き留めないでください。むしろ、コードを標準の取得方法にしてください。

いいえ、上記で説明したすべての理由によります（もちろん、ガイドラインが変更されたときにすべてのコードを一発でリファクタリングしない限り）。コードをそのままにしておきますか？現在のガイドラインを理解するために、コードベースをどのように検査しますか？ファイルの年齢で検索し、ソースファイルの年齢に合わせてコーディングスタイルを調整しますか？

良いデザインを立法化しないでください。（たとえば、gotoを使用しないように人々に伝えないでください）

確かに、ガイドラインは短くする必要があります。そうしないと、誰も読んでくれません。明らかなことを繰り返さないでください。

標準はコミュニケーションに関するものであり、それ以外のことは誰もが知っていることを確認してください。

それだけでなく、良い基準は品質に関するものであり、些細なことだけを基準にしたい場合を除きます。

最初の数回の反復の後、チームをまとめて決定します。

最初のポイントを参照してください。コーディング標準は通常、開発と改良に何年もかかったプロセスであることを忘れないでください。本当に？1人のシニア（ある場合）メンバーのメモリに依存しますか？

3つのメモ：

• 私の意見では、いくつかの言語の欠点は他の言語よりも深刻です。たとえば、C ++では、Javaよりも企業レベルの標準がさらに必要です。
• この推論は、チームが1つしかない非常に小さな会社で働いている場合、完全には当てはまらない可能性があります（ボブおじさんの理由はそれほど極端ではないかもしれません）。
• （チームとして）雇われ、1つの新しいプロジェクトで一人で仕事をし、それを忘れて先に進みます。この場合、あなたは気にしないかもしれません（しかし、あなたの雇用主は...）

1. 有用であるために、コーディング標準は実質の問題について話してはなりません。スタイルの問題だけ。arbitrary意的で曖昧なものだけを指定する必要があります。例：ブレースの配置、インデントの深さ、スペースとタブ、命名規則など。
2. スタイルの問題はローカルではなく、グローバルです。各チームは、それぞれのタスクと個性に合った独自のスタイルを採用する必要があります。これにより、標準がシンプルで軽量になります。企業の標準は、考えられるすべての考慮事項、構成、および例外で過負荷になります。
3. チーム内で、別のコーディングスタイルドキュメントを記述する唯一の理由は、チームによって生成されたコードが標準を満たしていない場合です。この場合、標準はありません。効果的であるために、標準はコード自体によって表現されるべきです。その場合、別のドキュメントは必要ありません。
4. レガシーシステムでは、チームとスタイルは時間とともに変化します。それには何の問題もありません。古いコードは古いスタイルになります。新しいコードは新しいスタイルになります。チームは、スタイルとその年齢を認識する必要があります。新しいコードを作成するときは、コードのどこに配置されていても、新しいスタイルにする必要があります。

コーディング標準を書き留めてはいけないのはなぜですか？

これには多くの理由があります。考慮事項は次のとおりです。

1. チームがコード標準のレビュー、議論、文書化、改訂などに多くの時間を費やすためだけに、コード標準の「学習」に費やす時間はどれくらいですか。これは、「従業員ハンドブック」を絶えず話し合うようなものです。チーム会議の議題でどのくらいの頻度でそれを達成しますか??

2. プロジェクトが払い戻されたり、棚に置かれたりしたときなど。残っている少数の人々は、通常、標準を遵守し続けることはできません（または、読んでさえいないかもしれません）。あなたが知っている次のこと、「コードをきれいに保つ」ためのすべての努力は、とにかくかなり無駄になりました。

3. プロジェクトが停止したり、新しいリードが持ち込まれたりした場合、その人は以前のルールを完全に無視し、新しい方法でやりたいと思う可能性が非常に高くなります。繰り返しますが、規格を体系化することで何が得られましたか？

必ず＃6を読んでください：

最初の数回の反復の後、チームをまとめて決定します。

言い換えれば、プロジェクトを開始する時が来たら、しばらくの間フローを続けるだけです。次に、現在のチームが使用しているコーディング標準の一般的な規則について話し合い、基本的にそれらに従います。そうすることで、製品の改善に費やす労力を最大限に活用しながら、実行可能コードを取得するための「シンタックスシュガー」の記述、レビュー、文書化に必要な労力を最小限に抑えることができます。

コーディング標準から大きなメリットを引き出すチームはほとんどありません。通常、「読みやすさ」はあまりにもあいまいです。ほとんどの開発者は、間隔や改行などに関する正確なルールから大きな恩恵を受けませんが、少なくともいくつかのルールを作成することで、常に煩わしい開発者を避けることができます。

私が十分に明確に述べられていないと思う別の答えは、それは人々が盲目的にルールに従わないことも意味するということです。それは、それを正当化するために書き留められたという事実だけに依存するのではなく、設計決定とコーディング規約の実際の正当化を考え出さなければならないことを意味します。

まず、私の知る限り、ボブおじさんは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。コードをに変更するのは簡単です。同様に、コーディング標準で条件または「空のステートメント」=内での使用が許可されていない場合、ビルドシステムの一部としてコードチェッカーを使用して、このエラーを追跡できます。ifif

コーディング標準に関する私の見解は、C / C ++から離れると大きく変わりました。厳密に施行されたコーディング標準が好きで、多くのページがありました。使用されているツールをリストし、いくつかの命名規則で元のチームメンバー間で非公式の合意を得るだけでよいと思います。私たちは、C / C ++でアプリケーションを作成する30人以上の開発者のチームの世界にはもはや住んでいません...

私がJScriptを好きにならなかったのには理由があり、TypeScriptが何年もの間Web開発に起こるのに最適だと思います。HTML / CSS / JScriptなどの設計の欠陥のために、Web UI開発者はまだコーディング標準を必要としています。

ソースを自己文書化コーディング標準にすることは、2つのことを意味します。

1. 熟練した貢献者になるためには、人々はコードベースを参照し、レビューしなければなりません。これは非常に重要です。コーディングガイドラインを読むことは、コードベースに飛び込むことに比べて時間の無駄です。
2. わずかな違いは重要ではないと認めています。基本原則に同意し、理解することが重要です。一貫したスタイルを維持することは、l'art pour l'artとして追求されていません。創造性のないピッカーが他の人を悩ませたり気を散らせたりすることは許されません。チーム内のコードを通じてコミュニケーションを促進することです。

頻繁に更新され、適切に記述されたコード標準ドキュメントは非常に役立ちますが、通常はそうではありません。標準文書は、企業が使用する実際のコーディング標準を反映していません。優れた標準文書を作成することは非常に難しく、最新の状態に保つことはさらに難しいからです。

貧弱で誤解を招くコーディング標準ドキュメントを作成する代わりに、何も作成せずに、コード自体にそれらの標準を表現させる方が良いでしょう。いずれにしても、最も重要な部分はコードに標準を適用することであり、これには単なるドキュメント以上のものが必要です。動機、プロセス、トレーニング、ツールなどがはるかに重要です。

十分に明確に述べられていない非常に重要なことは、コーディング標準が言語に似ているということです。それらは進化しています。文書化されたコーディング標準はこれを邪魔し、そうでなければ継続的に時代遅れで役に立たなくなります。

コーディングの標準が決まっていないことはそれほど悪くはありません。チェックイン時にピアレビューを行う場合、コーディング標準に準拠していない何かがリポジトリに入力されると、2人がそれについて考え*、このバリエーションの利点が残りのコードとの不整合を上回ると判断します。

書き留められた標準がないことは、会社のチームが新しいプロジェクトのコーディング標準の新しいバリエーションを試すことを妨げる赤テープも削除します。彼らが使用する自動化ツールのいくつか。

標準を書き留めると、本来意図されていたよりも柔軟性が失われる傾向がありますが、他のことをするのに費やすことができるかなりの時間を費やすことにもなります。特に異なる場所で作業するチームが同じコードベースで作業している場合、コーディング標準を書き留めてはいけないと言っているわけではありません。

強い関連性：コーディング標準の進化、どのように対処しますか？

*チェックイン時にコードをピアレビューしている間に人々が考えない場合、あなたの問題は単なるコーディング標準よりもはるかに大きいです。

それらを変更することは大きなハードルになり、人々は脳を使って正しいことをするのではなく、法の手紙を安全に守ります。

標準の一部が役に立たず、コードが悪化する日が来るでしょう。一部の人々は、それが書き留められており、安全であり、ルールに従う必要があるため、標準を遵守します。標準に準拠したコードよりも優れたコードを書きたい人は、イライラして怒ります。議論や意見の相違がありますが、標準が書き留められていなければ、調査と議論があります。

ここの多くの投稿がコーディング標準とスタイルガイドを混同していると思います。

異なるチームによって開発されたモジュールに同じコンパイラオプションがあり、ABIはインデントされているスペースの数とは異なる種類であることを確認します。

#includeファイルを構造化し、ヘッダーファイルのグローバル名前空間を汚染しない適切な方法のようなものは、初期コーディングおよびコードレビュー中にチェックリストとして使用できるように文書化する必要があります。

特に、「XXXはYYYとの互換性の問題を引き起こすため使用しないでください」は、他のコードにないため、次のコードの例では見られません。そのため、標準をキャプチャする方法をコードにすると、ある種の標準では不明確または完全に欠落する可能性があるため、これを普遍的な計画にすることはできません。

以下のように使用して例外を使用されていないか、真剣に普及し、重要な何かnew特定の組込みシステムにすることができないものとして、単に、共通の文化の知識であることを残され、「情報文化である（のみ）」という、ISO-9000のような製造基準の基本原則に反しますこれらの組み込みシステムの開発者は使用しています（例：自動車用途）。これらの重要なものは文書化され、承認され、正式な方法で提出される必要があります。

しかし、それはスタイルではなくコーディングに適用されます。

CおよびC ++の発明者は、例として、CaMelCaSeではなく小文字の名前の使用を示しています。それでは、なぜそんなに多くの開発者が、この暗黙の例に従わないのでしょうか？標準ライブラリのスタイルと標準的な教材は、従うべき暗黙のスタイルではありませんか？

一方、人々は__Ugly、マクロパラメータの名前の使用やインクルードファイルの非繰り返しパターンなど、コピーしてはならないものについては標準ライブラリヘッダーの例に従います。

そのため、ものを持っていることは重要なスタイルとは見なされないことが多く、逆に、プロジェクトコードで従うべきではない例については、例を持っていることが明確でない場合があります。どちらも、「スタイル」（またはコーディング規約）が暗黙的に残されるのが最善であるという論文の反例です。