每个人都有自己对于代码的看法，有自己的偏好。对于我来说，也是如此。作为一个实用主义者，我遵循的东西，比较少，也比较简单。多了，记不住，也不实用。
避免预先设计的代码
架构往往得预先设计的，而代码容易被过度设计。而事先设计的架构，往往在落地的时候，会遇到一系列的挑战。等到软件交付时，则会变成新的架构，或者该架构的变体。代码，则也是类似的。
日常工作中，我们经常遇到的情况，到底有没有必要提前编写一些代码——这些功能往往是，我们根据以往经验，猜测未来会有的功能？不事先编写，那么后期修改就比较麻烦。事先编写的代码，不符合需求，那么后期还是得重写。只有运气刚刚好，我们才能编写出符合需要的代码。然而，多数时候，我们写的这些代码往往是用不上的。
一旦代码中有大量多余的代码，代码看上去就没那么整洁了。若非要在两者做一个平衡，便是多做一点点，如先把接口准备好，但是不实现相应的功能。
IDE 重构 vs 手工重构
整洁的代码，意味着不重复，而每个人对于重复的定义是不一样的。对于我来说，则是：事不过三，过三则重构。耦合和参数，会带来新的复杂度。重构，不是一件容易的事，也不是一件太困难的事。
手工重构代码，意味着风险。如果没有测试，直接对代码进行重构，那么就会生不如死。
IDE 重构代码，则是依赖于 IDE 自带的功能，以通过机器的方式来重构代码。与手工方式相比，它更加的可靠，并且风险相当的低。前提是，该语言有对应的 IDE 可以提供这个功能，如 WebStrom、Intellij IDEA 等。
短、平的函数
编写函数的时候，要注意长度要短~、一个函数完成一件事，并且避免多级嵌套。
长的函数，阅读体验不好。多层嵌套的函数，复杂度过高。
采用各种 Lint 来限制函数的长度、层嵌套的数量，是一种颇为有效的降低复杂度的方式。
适当的设计模式与原则
设计模式和各种原则是好东西，它们可以方便我们与其他/她开发人员进行交流。当你遇到一个一对多的问题，别人一说，”你这个东西用观察者模式来实现”，那么问题就这么解决了。
设计模式，是一系列对于相关问题的解决方案。缺少编程经验的时候，学习设计模式，是一个不错的提升方式。而问题的关键，在于如何在适当的时候使用它们。在这个过程中，我们经历这么一些情况：
不知道设计模式
拿着设计模式的锤子（定律），到处使用
对设计模式反感，会避免使用
自然而然的使用设计模式
编程语言在解决问题上是相通的，哪怕是不同范式的设计语言，要解决的问题是一样的，采用的设计模式也就类似。
命名而非注释
命名，对于程序员来说，是一个难题。
一个好的变量名、函数名，远远比一行行注释，更重要——代码是写给人看的。
阅读遗留系统代码的时候，最怕的不是又长又深的代码，而是代码中有个 42 这种魔法数字（magic number），又没有对应的注释。那怕得打出几个电话、发几十条信息，才能知道这该死的 42 到底是什么。
哪怕是使用错误的单词，将 42 赋予这个变量，如 var ratio=42，也远比 42 + 对应的注释拥有更好的可读性。特别是，如果到处是这个 42 的变量，只会使得到处都是相关的注释。同样的，这个问题，也出现在对于函数的命名上。好在我们对于函数的命名，会略微重视一些。
结论
你还有哪些奇技淫巧呢？
“我自己是一名从事了10年的老程序员，辞职目前在做讲师，今年年初我花了一个月整理了一份最适合2018年学习的c++干货，从最基础的到深入的都有整理，送给每一位编程小伙伴，这里是小白聚集地，欢迎初学和进阶中的小伙伴。"
加QQ群：953788065（招募中）
网友评论