我从事C ++编程已经四年了，而Java编程已经两年了，我觉得我对他们自己的语言有很强的掌握，尽管我都不是向导。看来，一旦我达到了75％的完成标记，我的代码就好像是一团糟的意大利面烂摊子，有时到了无法阅读的地步。我们做了什么工作才能产生出良好的可读性代码？

解决方案

单元测试！！！如果我们有单元测试，则似乎要强制模块化，因为要能够编写(好的)单元测试，我们需要具有易于测试的小型组件，否则，这些单元测试将永远不会被写入=

阅读史蒂夫·麦康奈尔(Steve McConnell)出色的著作《代码完成》(Code Complete)。如果我只推荐每位软件开发人员都应该读的书，那就好了。

阅读完整的代码。这是良好编码实践的最终参考。

维护自己的凌乱代码的经验也会教给我们;)

我遵循的算法非常简单：

• 研究我们认为不错的代码
• 确定我们学习的代码的哪些方面比代码更好
• 改进代码，直到我们对代码的读取感到满意为止

稍后，我读了《重构：改进现有代码的设计》一书(Amason链接)。它包含有关使用Java和Python示例的简洁代码的dos和dont-s的具体建议。

当我们发现不良的设计决定开始引起问题时，要及早学会识别正在发展的意大利面条，并毫不留情地进行重构。

我们应该始终注意已写的内容，并在意识到可以做得更好的情况下乐于更改。但是，关键是能够及早识别这些问题，以便我们花费最少的时间来修复它们。

找到了对我有用的设计机制。
倾向于像边缘的东西。
即，我"知道"或者认为我做了，较低层需要做什么，并且"知道"顶层接口是什么。
这样一来，我们就可以相当早地生成某种工作代码，并且更易于保持模块化。

正确的答案可能应该是设计整个产品，但以我的经验，我们通常没有机会/能力做到这一点，因此请尽我们所能来做得更好。

编写Solid Code和Code Complete是有关代码质量的很好的参考书，但是要实现良好的设计要困难得多，因为我们都认为我们的编程问题是独特的。

几次失败。编写代码时，几个月后再回顾一下，找出可行的方法和无效的方法。失败是我们最大的优势，因为我们可以使用它们来改善自己的未来努力。

改写@jxie：测试驱动开发既需要并创建解耦的代码。

重构书对我编写好的代码的想法产生了较大的影响，但这可能只是因为它在正确的时机打了我。

使代码干净整洁。很多。对思考很​​有帮助。

通过重构很容易避免使用意粉代码。有了单元测试时，重构很容易完成。测试驱动开发迫使我们在编写代码之前先编写单元测试。 TDD将向我们显示代码是否易于使用以及设计是否直观。

因此，要回答问题，我会说我们需要在工具箱中添加TDD和重构。

务必阅读其他人的代码。这可以从许多方面了解如何改善设计实践。

我还下载了StyleCop。这有很大帮助！！！

在可读性方面，我已经形成了许多小习惯，这些习惯可以使我的代码保持"可见"，换句话说，可以使我清楚地看到一个屏幕，并知道哪些代码块在那个屏幕上。

使用大量空白。我在所有内容周围放置空格。没有什么比让我读代码更麻烦的了，在该代码中，一些"聪明"的程序员将所有运算符打包在一个等式中，没有空格。他认为他在帮助谁？编译器？

方法要简短。如果一种方法正接近屏幕上的所有文本，请将其分成较小的方法。

不断重构。不用说，而使方法简短则是其中的一部分。

丢掉代码。我通常至少写两次。我将编写一个完整的解决方案，并充分了解其结构不良。一旦完成，我将把整个事情扔掉，然后重新开始，但是现在有了关于该问题的更多知识以及期望的陷阱。

我坚决支持通过口头禅学习。我们编写的代码越多，我们在其他开发人员的代码上投入的工作就越多，我们对开发的了解也越多，代码就会越出色。教程经常使用错误的做法和错误的形式，因为它们试图讲授一般概念。真正的生产级代码是我们想要处理，研究和呼吸的内容。并非我们拥有的每一项工作都将拥有完美的代码，但是我们从该代码中看到并学习的越多，开发人员就越出色。对改进工作充满热情，并采取行动。阅读我们从未见过的代码，查看有关安全性，框架和运行时的文章。应用这些知识，很快所有知识就会渗入工作中。

由于重构的主题已经浮出水面，因此我建议使用具有良好构建的重构工具(如Eclipse)的IDE。

更改变量名，类名和分解类只是重构工具中的一部分，它们非常简单。对我来说，仅凭重构的能力就让我放弃了我正在使用的文本编辑器(除了最简单的项目以外的所有项目)。

由于我们说过使用Java和C ++，因此Eclipse可能是一个不错的选择，因为它支持两种语言。 (分别通过Java开发工具和C / C ++开发工具。)

如果IDE已经具有重构功能，请使用它们！它可以重组代码以减少混乱。

• 了解听众(其他程序员，开发人员，架构师，项目经理)
• 与他人进行代码审查。
• 在域(业务和客户)中建模对它们有意义的类/对象。
• 阅读Code Complete(尽管我只有9章内容)。

不一定按优先顺序排列。

我记得我不喜欢别人的代码，那些使它草率的事情。但最重要的是，让我拥有良好编码习惯的原因是，阅读了我以前无法阅读的代码，并想知道自己在想什么。所以现在当我编写代码时，我想这样做，以便当我再次阅读代码时确切地知道自己在做什么。

最近，我参与了在相对较短的时间内重构一个相当大的项目。这就要求我们执行某种重构分类。我们为提高可维护性和可读性而选择的目标如下：

删除未使用的代码

任何未调用的代码都不应成为项目的一部分。

这包括注释掉的代码或者没有用例的代码。

清理评论

代码主体中的注释应尽可能简洁，仅存在于无法理解的代码中。

但是，如果代码无法理解，则可能应该改写它。

应该注释类，函数和结构的外部接口，但是注释应该是关于如何使用接口的，而不是暗示的工作方式。

扁平化继承层次结构

使用继承来表达"是"关系。

继承对于多态性很有用(就像我们使用Interface一样)。

不利于代码重用，对于这种情况，组合会更好。

遵循一致的编码标准

命名约定

档案结构

避免使用"幻数"，而使用命名常量

阅读大量的代码和大量的书籍。例如浏览www.koders.com