使代码看起来“漂亮”有什么好处？

有时，我花费大量的时间（小时）来使代码“看起来很漂亮”。我的意思是使事情看起来对称。实际上，我将快速滚动浏览整个班级，以查看是否有任何东西因为看起来不“漂亮”或“干净”而跳出来。

我在浪费时间吗？这种行为有任何价值吗？有时，代码的功能或设计甚至都不会改变，我只是重新组织它，使其看起来更好。

我是完全被强迫症吗，还是隐藏着一些好处？

使用自动格式化程序。如果您确实在手动编辑代码上花费了很多时间，那么我会猜想您并没有受到很大的挑战/无聊，因为绝对没有理由这样做。VS中的Ctrl + K，Cntrl + D将格式化整个文档。如果您想要重量级的东西，可以使用Style Cop之类的东西。

对代码感到骄傲是一件好事，但是不要以牺牲智能为代价（寻找最有效的解决方案。在这种情况下，使用工具来完成繁琐的过程）并完成任务（还有什么可以做的）？您在那几个小时内从事过工作？）。

如果您没有更改任何可以更好地理解它的内容，那么您是在浪费时间。

没有隐藏的漂亮代码易于阅读和维护。

除非您拥有庞大的代码库，否则“小时”似乎有些多余。并非每件事都必须是完美的，而必须是完美的

这是一个判断问题；如果您要花几个小时，我会说您正在努力。但是，有些事情是人类可以做的，而自动格式化程序则做不到，并且您可以做一些使代码更具可读性的事情，而这些事情在公司编码标准中很难捕获。

例如，在类中声明变量时，我喜欢进行逻辑分组-这样可以更容易地遵循逻辑。

代码通常被认为是“一次写入，多次读取”，因此使阅读体验愉快是一个好习惯-但是我认为布局远没有明确的命名约定，简洁的抽象以及结构良好的方法签名那么大。

我已经看到格式精美的代码，由于潜在的思维过程存在缺陷，导致了严重的WTF时刻。如果您有几个小时要花，我会把它花在设计和重构上，而不是花在布局上。

不，您不是完全强迫症。我曾经作为程序员听到过的最大赞誉是：“您的代码很干净，我的弟弟可以弄清楚。”

有一天，有人将不得不支持您的代码。干净的代码更容易支持。有一天可能是你。在6个月或一年内，您将不会记住自己的所作所为。但是，如果它干净且易于阅读，它将很快回来。

这就是说，如果代码是垃圾，那么将其变成垃圾就无济于事。但是，如果结构合理且仅存在功能性问题，那么改进功能将容易得多。

痴迷于使代码看起来很漂亮是没有意义的。

以下是一些我认为有用的智慧：

询问为什么代码需要整理。

您可能会或可能不会在浪费时间，具体取决于您对pretty的定义。

格式化基本定理说，良好的视觉布局表明程序的逻辑结构。使代码看起来很漂亮是值得的，但比显示代码的结构还值钱。[第732页，代码完整第二版，史蒂夫·麦康奈尔]

如果您使用并发版本系统来跟踪代码中的更改-请勿在同一提交内将代码格式的更改与逻辑/添加功能的更改混合使用。

如果其他团队成员正在编辑文件，这将使更改更难以发现，并且将导致不必要的合并冲突。如果必须更改格式，请检查其他团队成员是否不在该文件上工作。[原文，Pg 93，使用Subversion的实用版本控制，第二版]

马丁·福勒（Martin Fowler）也在谈论“戴两顶帽子”并在一整天之间切换。一顶帽子用于添加功能，一顶帽子用于重构。

1. 您考虑添加新功能（功能帽）
2. 您细读现有的代码以获取理解，并在进行过程中进行整理。（重构帽子）
3. 提交更改。
4. 添加功能。（功能帽）等等。

[释义pg 57ish，重构，马丁·福勒（Martin Fowler）]

因此，不要花费数小时来美化整个代码库。只需美化您需要的足够的代码即可添加下一个功能。

简而言之...让每段代码都比刚到达时更好。

如果纯粹是格式化，那么最好花一些时间教一个漂亮的打印机如何格式化代码。这在前期有点昂贵，但是我想您会收回2-3个计时器的使用时间。

如果是实际的重构，可能不是。从概念上讲，干净的代码趋向于更容易进行修改，而“总是干净的”则减少了仅因为周围还有其他臭味的代码而使某些内容通过的诱惑。

它有一点帮助，但是不值得花很多时间在上面。还要确保您的改进也确实添加了变量作用域，RAII，组复制/粘贴的代码等。如果执行所有这些操作，则一年后必须了解代码的作用会变得容易1000倍。

您应该生成干净的代码，但是不需要花几个小时。

对于C语言，在eclipse中有一个gnu程序gnu-indent gnu-indent，至少有一个Java的代码格式化程序，我想也有大多数其他语言的工具。如果您出于特定目的想要违反规则，则只需单击几下即可正确缩进文件；如果我想针对简短的switch-case语句这样做，则只需几分钟即可：

 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

特别是以下列表：

好的，到目前为止，我已经提到了作为程序员的三个成就水平：

1。你不知道干净与不干净。

2。您对清洁有一个肤浅的想法，主要是在符合编码约定的级别。

3。您开始闻到表面下不整洁的微妙提示，它们使您烦恼不已，无法接触并修复代码。

不过，还有一个更高的层次，那就是我真正想谈论的内容：

4。您故意以某种方式构建代码，以使您对代码的不洁性大打折扣。

这是真正的艺术：通过从字面上发明使错误在屏幕上脱颖而出的约定来创建健壮的代码。

“小时”？好吧，我想说的是，答案是“与”，而不是“或”：是的，您正在使用OCD，但这样做有一些好处。

大概。

它使您的代码更容易快速阅读吗？它是否使浏览更容易，找出在哪里停止和开始，查找函数，变量等变得更容易？它使您的代码工作方式更清晰吗？整理过程是否会迫使您重新审视一些设计决策，并修剪最终放弃的死代码或剥离的半熟解决方案？如果是这样，它绝对具有价值。

另一方面，如果您想出了一种反您自己的审美观念而又不实际使您的代码更易于使用的不正确的方式，那么是的，这真是浪费时间。

对于我而言，我本人倾向于掉在强迫症的尽头，但我不会停下来。为类或函数提供文档的行为使我不得不思考事物的真正工作原理-我正在编写它，以便毕竟不是我的人可以理解它。而且，如果我发现自己对代码为什么会按其工作方式进行一连串警告，警告和歉意，那是一个非常强烈的警告，它需要在我声明完成之前再进行一轮调整。

首先，使代码看起来很漂亮没有错，因为最终您要为自己的创建而感到自豪，而代码的表示/格式化是其中的一部分。

但是，为了您的同事或未来的开发人员，在不过度格式化您的代码时，我会格外小心。对你漂亮对我可能不漂亮。:)

您识别出问题（强迫行为）和症状（强迫性地格式化）。

那原因和治愈方法呢？

• 你工作时间太多吗？
• 您是否感到沮丧，无聊，焦虑？
• 您的下一个任务是什么？这是你不想做的事吗？
• 您上一次假期是什么时候？晋升？认可成就？
• 是倦怠相关的问题吗？
• 你要死了吗？

有时，这些症状表明是时候进行大胆的改变或继续前进了。

尽管标题较低，但Yourdon的书中有许多有用的建议，对于许多组织来说，这是一个非常真实的描述。

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

您似乎很有见识，我想您可能知道答案。

现在，请允许您对其采取行动。

牛！
你们从未听说过缩进吗？

其代码格式化实用程序已有20多年的历史了。它有大量的选项，因此您可以按照自己的意愿自动格式化代码。

ermm-但它仅适用于C和某些（但并非全部）C ++。...（wtf？为什么GNU不升级它？）