コードを「きれいに」見せることに執着する利点はありますか？

ときどき、コードを「きれいに」見えるようにすることに苦労してばかげた時間（時間）を費やします。私は物事を対称的に見せることを意味します。実際にクラス全体をすばやくスクロールして、「きれい」または「きれい」に見えないものが飛び出すかどうかを確認します。

時間を無駄にしていますか？この種の動作には何か価値がありますか？コードの機能やデザインが変更されないこともあるので、見た目が良くなるように再構築します。

私は完全にOCDなのでしょうか、またはこれにいくつかの利点が隠されていますか？

自動フォーマッターを使用します。もしあなたが本当にコードを手動で編集するのにそれほど多くの時間を費やしているなら、私はあなたがそれほど挑戦/退屈していないと思います。それは全く理由がないからです。VSのCtrl + K、Cntrl + Dは、ドキュメント全体をフォーマットします。もう少し重いものが必要な場合は、Style Copなどを使用できます。

あなたのコードに誇りを持っているのは良いですが、ではない、それはの犠牲になったときにスマートであること（最も効率的な解決策を探している。この場合、面倒なプロセスを自動化するツールを使用して）と、物事は終ら他に何ができました（あなたはそれらの時間に取り組んでいますか？）。

それをよりよく理解できるようにするものを何も変更していないなら、はい、あなたは時間を浪費しています。

隠されているものは何もありません。きれいなコードは読みやすく、保守も簡単です。

ただし、巨大なコードベースがない限り、「時間」は少し過剰に見えます。すべてが完璧である必要はありません

それは判断の問題です。あなたが時間を費やしているなら、私はあなたがトップを超えていると言うでしょう。ただし、オートフォーマッターではできない人間ができることや、コードを読みやすくするためにできることはありますが、それは企業のコーディング標準では捉えにくいものです。

例えば、クラスで変数を宣言するとき、論理的なグループ分けが好きです-論理に従うのが簡単になります。

通常、コードは「1回だけ書き込み、多数読み」と見なされるため、読書体験を快適にすることは良い習慣です。

根本的な思考プロセスに欠陥があったため、深刻なWTFの瞬間を引き起こす美しくフォーマットされたコードを見てきました。何時間も費やすなら、レイアウトではなく設計とリファクタリングに費やします。

いいえ、あなたは完全にOCDではありません。プログラマーとして私が聞いた最大の賛辞は、「あなたのコードはとてもきれいなので、弟がそれを理解できる」というものでした。

いつか誰かがあなたのコードをサポートしなければなりません。クリーンなコードはサポートがはるかに簡単です。そしていつかはあなたかもしれません。6か月または1年後には、自分が何をしたかを思い出せなくなります。しかし、それがきれいで読みやすいなら、すぐに戻ってきます。

それは、コードがゴミである場合、きれいなゴミになるのに役立ちません。しかし、それがうまく構成されていて、機能上の問題がある場合、機能を改善するのははるかに簡単です。

コードをきれいに見せることに夢中になっていても、その点が欠けています。

ここに、私が役に立つと思ったいくつかの知恵があります。

コードが整頓される必要がある理由を尋ねる。

プリティの定義に応じて、時間を浪費している場合と浪費していない場合があります。

フォーマッティングの基本定理によると、優れた視覚的レイアウトはプログラムの論理構造を示しています。コードをきれいに見せることは価値がありますが、コードの構造を示すよりも価値はありません。[pg 732、コード完全版、第2版、Steve McConnell]

同時バージョンシステムを使用してコードの変更を追跡する場合-同じコミット内でコードのフォーマットの変更と論理的/機能の追加の変更を混在させないでください。

変更を見つけにくくし、他のチームメンバーがファイルを編集している場合、不必要なマージの競合が発生します。書式を変更する必要がある場合は、他のチームメンバーがそのファイルで作業していないことを確認してください。[言い換え、Pg 93、Subversionを使用した実用的なバージョン管理、第2版]

また、Martin Fowlerは「2つの帽子をかぶる」ことと、1日を通して帽子を切り替えることについて話します。機能を追加するための1つの帽子、リファクタリングのための1つの帽子。

1. 新しい機能を追加することを検討します（Feature Hat）
2. 既存のコードを熟読して、理解を深め、作業を片付けます。（リファクタリングハット）
3. 変更をコミットします。
4. 機能を追加します。（Feature Hat）など...

[PG 57ishの言い換え、リファクタリング、Martin Fowler]

そのため、コードベース全体を偽装しようとして時間を費やさないでください。次の機能を追加するために必要な十分なコードを指定してください。

要するに...あなたが最初に到着したときよりも良い状態に各コードを残します。

純粋にフォーマットする場合は、コードをフォーマットする方法をプリティプリンターに教えることに時間をかける方がよいでしょう。前もっていくらか費用がかかりますが、2〜3回の使用でそのタイマーを回収できると思います。

実際のリファクタリングの場合は、おそらくそうではありません。概念的にクリーンなコードは、今後の修正が容易になり、「常にクリーン」にすると、他の臭いコードがあるからといって、何かを通過させたいという誘惑が軽減されます。

それは少し役立ちますが、それに多くの時間を費やす価値はありません。また、改善によって変数スコープ、RAII、グループコピー/貼り付けコードなどが追加されることを確認してください。これらすべてを行うと、コードが1年ほど後に何をするかを理解する必要があるときに1000倍簡単になります。

きれいなコードを作成する必要がありますが、時間はかかりません。

Cには、gnu-program gnu-indent gnu-indentがあり、Eclipseには少なくともJava用のcodeformatterがあり、他のほとんどの言語にもツールがあると思います。ファイルを正しくインデントするには、数回クリックする必要があります。特定の目的のためにルールに違反する場合は、数分です（短いswitch-case-statementsの場合と同様）。

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

指定するのは難しいです。

スキミングで何かがきれいに見えると思うなら、自動化できる表面的なものに集中しています。

「間違ったコードの見栄えを悪くする」に関するこの古典的な記事を読むと、人々が一般的にインデント（これは自動的に実行できる）が些細であると考える理由が正確にわかります。

http://www.joelonsoftware.com/articles/Wrong.html

特にこのリスト：

OK、これまでのところ、プログラマーとしての3つのレベルの達成に言及しました。

1 あなたは汚れたものからきれいなものを知りません。

2。ほとんどの場合、コーディング規則への適合レベルで、清潔さの表面的な考えがあります。

３。あなたは表面下の汚れの微妙なヒントを嗅ぎ始め、それらはあなたに手を差し伸べてコードを修正するのに十分あなたをバグにします。

ただし、さらに高いレベルがあります。これは、私が本当に話したいことです。

4。コードを意図的に設計することで、不潔さのためにあなたのコードが正確になる可能性が高くなります。

これが本当の芸術です。画面上でエラーを際立たせる規約を文字通り発明して堅牢なコードを作成します。

「時間」？さて、あなたの答えは「または」ではなく「または」であると思います。ええ、あなたはOCDですが、それにはいくつかの利点があります。

多分。

コードを読みやすくしますか？スキミング、どこで何が止まり、どこから始まるのか、関数、変数などを見つけやすくなりますか？コードの動作がより明確になりますか？整理のプロセスにより、いくつかの設計上の決定を再検討し、デッドコードを除去したり、最終的に放棄した中途半端なソリューションを排除したりしますか？もしそうなら、それは絶対に価値があります。

一方、コードを実際に操作しやすくすることなく、自分の美的感覚にアピールするためのいくつかのひねくれた方法を見つけたなら、そう、それは時間の大きな無駄です。

私に関して言えば、私はこのことのOCDの終わりに陥る傾向があります-しかし、私はやめるつもりはありません。クラスまたは関数のドキュメントを提供するという行為は、私が物事が実際にどのように機能するかについて考えることを余儀なくされます-私はそれを書いているので、私ではない誰かが結局それを理解することができます。そして、コードがそのように機能する理由について多くの警告と警告と謝罪を投げていることに気付いた場合、それは私がそれを宣言する前にもう1ラウンドの微調整が必​​要な非常に強力な警告です。

最初はコードの見栄えを良くするのに何も問題はありません。最終的には、コードの作成と表示/書式設定を誇りにしたいからです。

ただし、同僚や将来の開発者のためにコードを過剰にフォーマットしないように注意します。あなたにとってきれいなのは、私にとってきれいではないかもしれません。:)

問題（強迫行動）と症状（強迫観念的なフォーマット）を認識します。

原因と治療はどうですか？

• 長時間働いていますか？
• 欲求不満、退屈、心配ですか？
• 次の仕事は何ですか？やりたくないことですか？
• 最後に休暇をとったのはいつですか？昇進？成果に対する認識？
• それは燃え尽き症候群関連の問題ですか？
• あなたは死の行進にいますか？

時々、これらの症状は、大胆な変更を行うか、先に進むときのサインです。

ダウンドンのタイトルにもかかわらず、Yourdonの本には多くの有用な提案があり、多くの組織にとって、かなり現実的な説明をしています。

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

あなたはかなり洞察力があるようで、答えを知っているかもしれません。

ここで、自分で行動する許可を与えます。

聖なるウシ！
あなたはインデントを聞いたことがありませんか？

そのコードフォーマットユーティリティは、20年以上使用されています。そのオプションのメガバケットを持っているので、あなたのコードはあなたが望むように自動的にフォーマットすることができます。

ermm-しかし、それはCでのみ動作しますが、すべてではありませんがC ++で動作します。...（wtf？なぜGNUアップグレードしないのですか？）