有关创建干净，优雅代码的提示

Question

编写干净，优雅的代码使编码成为我的乐趣。我一直在寻找更多方法。以下是我的一些策略/策略：

• 将大型代码块保存在较小的例程/方法/类中

• 确保每个例程都有一个退出点。退出循环顶部带有逻辑的循环，而不是中断或某种类型的“退出循环”关键字。

• 避免全局

• 如果您刚刚使用代码执行了复制/粘贴，则可以创建例程/类/库。

......最近我一直在玩弄一个人：

• 尝试用不同的方法签名替换if / branching / select案例（多态） 在YouTube上清洁代码会谈

Answer 1

Clean Code by Robert C. Martin

Answer 2

如果您还没有阅读“代码完成”，我强烈建议您停止阅读Stack Overflow几天（或者需要多长时间），然后再阅读。

alt text http://ecx.images-amazon.com/images/I/51seLiYuURL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

Answer 3

“一，二，多”。

在这个星球的某个偏远角度，一个偏远的野生人口在他的语言中没有任何词语可以超过两个。两个人之后，有一个词是“很多”。 我以前的老板鼓吹这句话来保持例程中参数的数量。我倾向于同意他的意见。

“不要重复自己（干）”

如果你在两个地方说同样的话，那你就有问题，你应该重构。两个（或更多）的地方迟早会被去同步。

“保持简单，愚蠢（KISS）”

不要过度设计。

Answer 4

不要拖延。永远。当你想到一种改进代码部分的方法时，那就去做吧，无论它有多难，或者需要多长时间。始终寻找潜在的改进，永远不要轻松出路。

现在，这不是开发代码的最有效或最有利可图的方式，这就是为什么专业代码库很少是美的例子。但这不是你的问题。

Answer 5

在Comp Sci中，我听到了一些始终困扰着我的事情：

“在编程中只有3个数字：0,1和无穷大。”

当然，实际的现实迫使我们使用其他数字。但是，如果我使用除这三个以外的数字，我总觉得我的代码变得不那么优雅了。

Answer 6

是的，那些都很好。

我认为最好的一个是假设第一个版本不是最终版本。计划重写和重构。看看小块，想想如何更优雅地完成它们。

另外，阅读代码，特别是已知的好代码。

Answer 7

  

- 在较小的例程/方法/类块中保存大型代码块

我喜欢做的是首先创建一个主要功能，所以我不必从一开始就创建大量的迷你功能，阻碍了我的思路，然后将其重构为更小的功能。重构很棒。

  

确保每个例程都有一个退出点。退出循环顶部带有逻辑的循环，而不是中断或某种类型的“退出循环”关键字。

这不一定更清洁。它只是更容易证明函数的正确性。有关详细信息，请参阅Should a function have only one return statement?。

  

避免全局

有时候全局变量也没关系。很多时候人们使用单身只是为了避免使用“全局”，这实际上是一种伪装的全局性，而且开销更大。

Answer 8

通常，干净的代码与短函数或更好的缩进相关联。所以不要陷入那个陷阱。花大量时间设计课程。有一些很好的原则，例如SOLID principles，可以让你设计和建立好的有意义的类。然后选择合适的设计模式来模拟类的行为。当然要记住遵循保持简单的原则。最后，确保您的架构中的复杂功能有足够的代码覆盖率。遵循所有这些可以帮助您编写干净的代码。我向朋友和同事推荐这是一个很好的list of books。

Answer 9

虽然可能并不完全是您正在寻找的答案类型，但我认为基于组件的设计倾向于通过优雅的架构来实现优雅的代码。考虑如何隔离代码将结构和顺序应用于其他混乱的过程（有时）。代码优雅可以在预先实现之前（最好是彻底），或者通过重构和简化进行初始集成后进行。如果您使用基于组件的模型，那么重构应用程序的整体部分将变得更易于管理 - 只要输入和输出在美化/简化过程中保持不变即可。对我来说，专注于整体应用程序结构已成为优雅代码的关键。除非你的应用程序范围很小，否则很难在没有前者的情况下实现后者。

底线是代码是一个可塑性且不断变化的过程。优雅只是在不同的时间点，因为有些东西可以开始优雅，经过几次迭代后变成了污点。在那之后，它再次被重构为优雅等等，这就是为什么通过声音架构支持这个想法将使您更容易保持代码尽可能优雅，而不会破坏不相关的项目。