コードフォーマットのガイドラインはどれくらい重要ですか？[閉まっている]

コーディング標準はどのソフトウェア開発組織でも一般的ですが、それに従うことはどれほど重要ですか？ある程度の一貫性の必要性は理解できますが、ブレースの位置、行の長さなどの単純なものを扱う場合、過度に厳しい標準がソフトウェア開発に大きく寄与するかどうかはわかりません。

事前定義された標準に準拠しているのではなく、コードが読みやすいことが重要ではありませんか？とにかくガイドラインに似ているようです。

すべての人に同じ標準のコードフォーマットガイドラインを100％遵守するように依頼することは、同じ執筆スタイルで100ページの論文を書く際に、全員に個別に協力するよう求めることと似ています。

みんなが論文を英語（または同じ言語）で書くことを願っていますが、異なるスタイルが明らかになります。うまく書く人もいれば、そうでない人もいます。収縮を使用する人もいれば、単語を完全に綴る人もいます（例：それは真実です）。等。

最も重要な点に触れたと思います。

1. それはガイドラインです
2. 読みやすさ

紙のように同じ書き方をするように、コードを同じフォーマットに準拠させる場合は、編集と修正が必要になります。コードはクリーンアップ、レビュー、リファクタリングなどが必要です。

私は、別の開発者のコ​​ーディングスタイルやフォーマットに完全に満足しているショップに行ったことがありません（最小限ではありません）。しかし、私はそれを読んだり理解したりすることができ、一貫していれば満足しています。 それ以外はすべて、構文糖上の糖です。

だからあなたの質問に答えるために：やや重要ですが、そうでない場合、それは確かに世界の終わりではありません。

標準化のフォーマットについては、私は他のみんながやっていることに従います。彼らがすべてにPascalCaseを使用している場合、PascalCaseを使用します。_camelCaseを使用する場合は、_camelCaseを使用します。どうして？それは私が行う再フォーマットの量を制限し、他の人がそれを「見栄えよくする」ためにしなければならないことを制限するからです。通常、フォーマット標準は、すべての人にとって物事を簡単にするためにあります。

現在の仕事で、最初の仕事の1つは、開発グループのコーディング標準を考案することでした。

私の最初の努力は約60ページの長さでした（Microsoftのフレームワークガイドラインの多くを取り入れました）。私はそれを削減するように頼まれました、そして、私の次の努力は様々な良いソースからのアイデアを利用して、10ページの長さでした。私は再びそれを削減するように頼まれ、最終的に3または4ページにそれを下げたと思います。

採用されたことはありません。

どうして？私はすでに賢明なコーディング標準に本能的に従っている多くの本当に頭の良い人々と仕事をしているからです。

私は、Microsoftから一般に認められているガイドラインに従い、一般的に使用されている他のスタイルをエミュレートします（JavascriptとjQueryは、どちらも中括弧言語ですが、C＃とは異なる形式です）。また、規則を時々破ります。そうすると、コードが読みやすくなります。

この基本を実行するIDE（Visual Studioなど）を使用する場合、IDEにそれを実行させ、IDEにそれを実行させる限り、変更するのが難しいと思われるものを変更するか、それを自動フォーマットする次の人はとにかくそれを殺すつもりです。

1人にとって最も読みやすいのは、すべての人にとってではありません。

この種のIDEを使用していない場合は入手してください。これについて10分以上考えても、リソースは無駄です。

コードをすばやく理解するのに役立つことには、言及されていない利点があると思います。コードの書式設定がプロジェクトとすべての開発者に共通しているほど、コードを簡単に（そして無意識に）使用できるようになります。

単純なバグでさえも長期間にわたって対処しようと試みた後、ジュニア開発者を訪ねてきました。彼らにコードフォーマットを適用するのに数分かかった後、彼らは以前見逃していたバグをすぐに見ることができました。

読みやすさは間違いなく重要です。コード形式の標準がよく考えられていて、適切に使用されている場合、コードを読むだけでなく、コードをさらにすばやく理解できるようになることもあります。

コーディングフォーマットを開発または更新するときに使用するガイドラインのセットは、Gestalt Principles of Grouping- http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_groupingです。

直接的な結果/例として、コードの書式設定では、ブロックコード（if、switchなど）に次の行に開き中かっこが必要です。

if(true)
{
}

対称性の原理により、あなたの心は開いた括弧と閉じた括弧を見て、より迅速に自然にコードブロックを認識することができるという推論で。

使用する言語やツールに関係なく、何かを考え出します。IDEを構成し、構成ファイルをチェックインします。

誰かがプロジェクトをチェックアウトするとき、同じフォーマットスタイルを使用します。スタイルが何であるかは問題ではなく、一貫しているだけです。スペースとタブ、および中括弧が続く行に関しては、私自身の好みがあります。しかし、私自身の好みよりも、特定のソースコードファイルが自分自身と一致することだけを気にしています。それは、フォーマット戦争に起因するミッシュマッシュであるよりもはるかに読みやすくします。

私がこれまで遭遇した最悪のことは、コーディング標準を使用していないことです。diffツールを壊すため、コードブロックを読みやすくすることは禁止されています...変更を適用するためにパッチを使用しているため（変更/バグ修正要求->修正/変更->パッチ->「信頼できる」人によって適用されたパッチ->コミット）（読みやすさの観点から）かなりおかしなソースコードを取得できます。少なくとも、2文字の変数を使用している人はいません（-。

[暴言]最もおかしいのは、これを変更する必要があることに全員が同意することです。いくつかの再フォーマットの試みもありました（コミット時に自動化されました）が、1つの小さな非常に厄介なフォーマットオプションが欠落しているため、すべてがうまくいきました。視力... [/暴言]

ガイドラインは、コードの品質向上に役立ちます。

• 作家の観点から：多くのルールはバグの導入を減らすことを目指しています。たとえば、単一の命令ではなくブロックif()またはfor(;;)ブロックが続く必要があることを示すルールは、初期コーダーの意図を明示し、次のコーダーがこれを維持するのに役立ちます。

• 読者の観点から：合意されたガイドラインに従うコードは、さまざまなスタイルのコードよりも効率的にレビューされます。レビューアは、起こりうるバグをどこで探すかをより少ない労力でよく知っています。

チームが何をすべきか、すべきでないかについての普遍的な基準はありません。厳格なガイドラインに従う必要があるチームもあれば、そうでないチームもあります。

ポイントは、チームとして協力して、チームに最適なものを決定する必要があるということです。コードは、書き込まれるよりも桁違いに多く読み取られるため、読みやすいはずです。チームが読み取り可能なコードを作成するためのガイダンスが必要な場合は、コーディング標準に従ってください。そうしないなら、しないでください。

そうは言っても、ほとんどのチームは、変数、関数、クラスに名前を付ける、ブレースを配置するなどの標準的な方法に同意することで恩恵を受けると思います。チームがそれほど簡単なことに同意できない場合、どうやって一緒になって本当に重要な決定を下すことができるのでしょうか？さらに、あなたのチームは永遠に同じ人で構成されることはありません-人は去り、新しい人は雇われます。新しい人がコードベースを簡単に理解できるほど、コードの品質を落とすことなくチームに貢献できます。