コードフォーマットガイドラインはどのくらい重要ですか？
コーディング標準はどのソフトウェア開発組織でも一般的ですが、従うことがどれほど重要ですか？ある程度の一貫性の必要性は理解できますが、ブレースの位置、行の長さなどの単純なものを扱う場合、過度に厳格な基準がソフトウェア開発に大きく貢献するかどうかはわかりません。
定義済みの標準に準拠しているのではなく、コードが読みやすいことが重要ではありませんか？とにかく、ガイドラインに似ているようです。
すべての人に同じ標準コード形式のガイドラインを100％遵守するよう依頼することは、同じ書体で100ページの紙を書くことについて全員に個別に協力することを依頼するようなものです。
うまくいけば、全員が英語（または同じ言語）で論文を書くことができますが、異なるスタイルが明らかになるでしょう。うまく書ける人もいれば、書けない人もいます。一部は短縮形を使用し、一部は単語を完全にスペルアウトします（例：それはそれが正反対です）。等。
私はあなたが最も重要な点に触れたと思います：
- ガイドラインです
- 読みやすさ
紙を同じ書体にするなど、コードを同じ形式にしたい場合は、編集して修正する必要があります。コードのクリーンアップ、レビュー、リファクタリングなどが必要になります。
私は、他の開発者のコーディングスタイルやフォーマットに完全に満足している店に行ったことはありません（少なくとも私のものとはまったく違うので）。しかし、私がそれを読んだり理解したりでき、一貫していれば、満足しています。 それ以外はすべて、構文上の砂糖の砂糖です。
ですから、あなたの質問に答えてください：やや重要ですが、そうしなくても、世界の終わりではありません。
標準のフォーマットについては、私は他の誰もが行っていることに従います。すべてにPascalCaseを使用している場合は、PascalCaseを使用します。 _camelCaseを使用している場合は、_camelCaseを使用します。どうして？それは、私が行う再フォーマットの量を制限し、「見栄え」を良くするために他の人がしなければならないことを制限するからです。誰にとっても物事を簡単にするために、フォーマット標準が通常あります。
私の現在の仕事では、最初のタスクの1つは、開発グループ用のコーディング標準を考案することでした。
私の最初の取り組みは約60ページでした（Microsoftのフレームワークガイドラインの多くが組み込まれていました）。私はそれを減らすように頼まれました、そして私の次の努力は様々な良い情報源からのアイデアを利用して、10ページの長さでした。私はもう一度それを切り詰めるように頼まれました、そして最終的にそれを3または4ページに下げました、私は思う。
それは決して採用されませんでした。
どうして？なぜなら、私はすでに本能的にコーディング標準に従っている賢い人たちと一緒に仕事をしているからです。
私は、Microsoftから一般に受け入れられているガイドラインに従い、一般的に使用される他のスタイルをエミュレートします（JavascriptとjQueryは、中括弧言語であるにもかかわらず、C＃から フォーマットが異なる です）。私は時々ルールを破りますが、そうすることでコードが読みやすくなります。
とIDEがこれの基本を行う（Visual Studioなど））を使用している場合は、IDEでそれを実行します。 IDEがそれを自動フォーマットする次の人がそれをとにかくそれを殺すつもりだということをやらせている限り、あなたが変更を見るのは難しいです。
一人が最も読みやすいものは、すべての人のためではありません。
この種類のIDEを使用していない場合は1つ取得してください。これについて10分以上考えても、リソースの無駄遣いです。
コードをすばやく理解するのに役立つことには、言及されていない利点があると思います。プロジェクトとすべての開発者の間でコードの書式設定が類似しているほど、コードをより簡単に（そして無意識のうちに）処理できるようになります。
簡単なバグでも長期間処理しようとした後輩に来てもらいました。彼らと一緒にコード形式を適用するのに数分かかった後、彼らは以前見逃していたバグをすぐに見ることができました。
読みやすさは間違いなく重要ですが。コード形式の標準がよく考えられ、適切に使用されている場合は、コードを読み取るだけでなく、コードをより迅速に理解できるようになる可能性があります。
コーディング形式を開発または更新するときに使用するガイドラインの1つは、グループ化のゲシュタルト原則- http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping です。
直接的な結果/例として、コードの書式設定では、ブロックコード（if、switchなど）の次の行に左中かっこを付けて、右中かっこに合わせる必要があります。
if(true)
{
}
対称の原則によって、あなたの心は開閉ブレースを見ることができ、より迅速にコードブロックを自然に知覚できるようになるという理由で。
使用する言語やツールに関係なく、何かを考え出す。 IDEを構成し、構成ファイルをチェックインします。
誰かがプロジェクトをチェックアウトすると、同じフォーマットスタイルが使用されます。スタイルが何であるかは関係ありません。一貫しているということだけです。スペースとタブ、および中括弧が続く行に関しては、私自身の好みがあります。しかし、私は自分の好みよりも、与えられたソースコードファイルがそれ自体と一致することを気にしています。これは、フォーマット戦争の結果生じたミッシュマッシュよりもはるかに読みやすくなっています。
チームがすべきこと、すべきでないことに対する普遍的な基準はありません。一部のチームは厳密なガイドラインに従う必要がありますが、従わないチームもあります。
重要なことは、あなたはチームとして協力し、自分のチームに最適なものを決定することです。コードは、書き込まれるよりも桁違いに多く読み込まれるため、読みやすいはずです。チームが読みやすいコードを作成するためのガイダンスが必要な場合は、コーディング標準に準拠してください。そうでない場合は、しないでください。
そうは言っても、ほとんどのチームは、変数、関数、クラスに名前を付けるための標準的な方法、中かっこなどに同意することで恩恵を受けると思います。チームがそのような単純なことに同意できない場合、どうすれば一緒に集まり、本当に重要な決定を下すことができるでしょうか。さらに、チームが永遠に同じ人で構成されることはありません-人が去り、新しい人が雇われます。新しい人がコードベースを理解しやすくなるほど、コードの品質を低下させることなく、チームにすばやく貢献できます。
これまでに遭遇した中で最悪のことは、コーディング標準を使用していないことです。また、一部のコードブロックを読みやすくすることは禁止されています。これは、diffツールが動作しないためです。変更を適用するためにパッチを使用しているため（変更/バグ修正リクエスト->修正/変更->パッチ->「信頼できる」人が適用したパッチ-> commit）（可読性の観点から）かなり面白いソースコードを取得できます。少なくとも、2文字の変数（-。
[朗報]おかしなことは、私たちがこれを変更する必要があることに誰もが同意していることです。いくつかの再フォーマットの試み（コミット時に自動化）さえありましたが、単一の小さなビットの多いフォーマットオプションが欠落しているため、すべてがうまくいきました。視力... [/ラント]
ガイドラインはコードの品質向上に役立ちます。
ライターの観点から：多くのルールはバグの導入を減らすことを目的としています。たとえば、
if()またはfor(;;)構文の後には単一の命令ではなくブロックが続く必要があることを示すルールは、初期コーダーを明示し、次のコーダーがこれを維持するのに役立ちます。読者の観点から：合意されたガイドラインに従うコードは、さまざまなスタイルのコードよりも効率的にレビューされます。レビューアーは、より少ない労力で、可能なバグを探す場所をよりよく理解しています。