建议编写更具可读性的代码？

Question

对于编写更易于理解的代码，您有哪些提示/建议？

我最近一直在维护的一些代码缺乏结构和错误的格式，这让我有些沮丧，并想提出一系列指导方针来编写更易于理解的代码。

任何建议都可能有所帮助，无论是什么语言。

问候。

Answer 1

我喜欢这些书：

• Clean Code
• Refactoring
• Agile Software Development

您还应该阅读代码。如果代码难以阅读，请问问自己作者到底做了什么或没做什么，这会让人难以理解，更重要的是，如何利用所学知识自己编写更好的代码。

Answer 2

我建议阅读以下内容：

• Pragmatic Programmer
• Clean Code
• Effective Java

Answer 3

1. 命名 - 函数、变量、类等... 一个好名字对使代码可读性大有帮助。名称应具有描述性和清晰性，并确保在事物的用途发生变化时更新名称。

2. 分解复杂的函数 - 我的经验法则是，如果我不能同时在屏幕上显示整个函数/方法，它可能做得太多，需要分解。

3. 可读性胜于聪明 - 与巧妙地使用语言的晦涩特性相比，他们可以在 5 年后阅读和维护的代码会给更多人留下深刻印象

我可以继续，但这是一个好的开始。

Answer 4

“如果你需要超过 3 级的缩进，那你就完蛋了，应该修复你的程序”——Linus Torvalds

Answer 5

试试这些：

• 最小化嵌套 - 嵌套的控制块越少，代码越容易阅读。
• 使用临时变量 - 虽然它们有时会让你的代码看起来很笨重，但它们也可以大大提高可读性。
• 分解大功能 - 将大功能分解为易于理解和测试的小型单一职责功能。

Answer 6

1. 保持干燥 - 不要重复自己
2. 保持方法小
3. 随手测试 - 您的单元测试将帮助您的设计、充当文档并保持您的代码正常工作。
4. 仔细命名方法和变量 - 一个经过深思熟虑的名称比注释更好。

Answer 7

有许多代码风格指南和启发式方法，但确保可读性的最佳方法是当有人编写代码时，其他人应该阅读它，然后对其进行批评。

Answer 8

看看 Google Web Toolkit 使用的Code style

真的不错

Answer 9

编写可维护代码的关键是遵循一些基本的代码设计原则：

1. 单一职责原则 - SRP - 一个类必须实现一个职责。
2. DRY - 与 SRP 几乎相反 - 不要重复自己 - 换句话说，不要让多个类实现相同的职责（因为这会导致重复相同的代码）
3. 制作应用程序的垂直切片并将每个切片称为模块。提出一个模块化结构，在模块之间具有明确的依赖关系。发布项目的模块结构并强制团队遵守它。显然没有周期性依赖。在构建期间使用 maven 或 apache ivy 等工具进行依赖管理。
4. 有一种方法可以使用 AOP、装饰器等策略将非功能性需求实现为横向需求。

有了这些东西，大部分代码将变得可维护。上面的每一点本身都非常复杂。我非常喜欢this book。

查看讨论这些事情的博客等。 万事如意

Answer 10

由于您已经在维护一个大型代码库，因此拥有一个良好的 IDE 并强制执行所有标准格式将有所帮助。将现有代码更改为更具可读性远不止于此。

从《重构：改进现有代码的设计》一书开始—— 马丁·福勒、肯特·贝克、约翰·布兰特、威廉·奥普代克、唐·罗伯茨”

Answer 11

选择coding style——任何编码风格——并使用始终如一（与团队中的其他人一起）。如果您使用一致的样式，您将习惯它和develop code smells，这会提示您使用糟糕的代码。

您可以使用许多工具来自动格式化您的代码，如果您使用 IDE，它可能有一个内置工具。

Answer 12

我想到了一些：

• 不要不必要地将this 放在方法前面，例如：

this.doSomething();

• 不要使用匈牙利语，例如：

private int mCount;

• 声明局部变量接近它们的使用位置，最好尽可能晚

Answer 13

似乎问题实际上是关于将不可读的代码转换为与编写新的可读代码不同的可读代码。

在做其他事情之前：

1. 如果尚未完成，请使用版本控制。
2. 如果尚未完成，请使用自动化测试。

一般来说，客户并不关心代码的可读性。客户非常关心软件是否按预期运行。

当您最初需要维护不可读的软件时，您就有了软件错误的替罪羊。但是，如果您的前任应客户要求修复了一个错误，而您无意中删除了该修复（可能非常难以阅读），那么客户将没有太多耐心。