易读

# 易读 ### 简介 ### 无关的编程经验 > 只要我有更多时间，我就会写一封更短的信给你。 从小学算起我的编程年限应该也有十几年了吧，笑~~。只是我过去的多年编程经验对于我现在的工作来说，是多年的无关经验(详见《REWORK》——多年的无关经验)。 高中的时候学习了点游戏编程，也因此学了点C++的皮毛，除了学会面向对象，其他都忘光了。随后在学习Linux内核，当时代码里就各种struct。比起之前学过的Logo和QBASIC简直是特别大的进步，然当时觉得struct与面向对象两者间没啥太大区别。在那个年少的时候，便天真的以为程序语言间的区别不是很大。 大学的时候主要营业范围是各种硬件，也没有发现写出好的代码是特别重要的一件事。也试了试Lisp，尝试过设计模式，然后失败了，GoF写DP的时候一定花了特别长的时间，所以这本书很短。期间出于生活压力(没有钱买硬件)，便开始兼职各种Web前端开发。 在有了所谓的GNU/Linux系统编译经验、写过各种杂七杂八的硬件代码，如Ada、汇编，要保证代码工作是一件很简单的事，从某个项目中引入部分代码，再从某个Demo中引入更多的代码，东拼西凑一下就能工作了。 多年的无关经验只让我写出能工作的代码——在别人看来就是很烂的代码。于是，虽然有着看上去很长的编程经验，但是却比不上实习的时候6个月学到的东西。 只是因为，我们不知道: 我们不知道。 ### 代码整洁 过去，我有过在不同的场合吐槽别人的代码写得烂。而我写的仅仅是比别人好一点而已——而不是好很多。 然而这是一件很难的事，人们对于同一件事物未来的考虑都是不一样的。同样的代码在相同的情景下，不同的人会有不同的设计模式。同样的代码在不同的情景下，同样的人会有不同的设计模式。在这里，我们没有办法讨论设计模式，也不需要讨论。 我们所需要做的是，确保我们的代码易读、易测试，看上去这样就够了，然而这也是挺复杂的一件事: 1. 确保我们的变量名、函数名是易读的 1. 没有复杂的逻辑判断 1. 没有多层嵌套 1. 减少复杂函数的出现 然后，你要去测试它。这样你就知道需要什么，实际上要做到这些也不是一些难事。 只是首先，我们要知道我们要自己需要这些。 ### 别人的代码很烂? 什么是很烂的代码? 应该会有几种境界吧。 1. 不能工作，不能读懂 1. 不能工作，能读懂 1. 能工作，很难读懂 1. 能工作，能读懂，但是没有意图 1. 能工作，能理解意图，但是读不懂 如果我们能读懂，能理解意图，那么我们还说他烂，可能是因为他并不整洁。这就回到了上面的问题，模式是一种因人而异的东西。 我们在做Code Review的时候，总会尝试问对方说： “这样做的意图是”。 对于代码来说也是如此，如果我们能理解意图的话，那么我们要理解代码相对也比较容易。如果对方是没有意图，那么代码是没救的。 ### 变量名 ### 函数名 ### 小函数 ### 测试