在写代码的时候，有一些技巧和方法已经快成为成为了众矢之的，主要还在于代码的可阅读性，以及易错性上。

被列为经典的几种方法或技巧中有一些还是能用尽量少用：goto、递归、状态机。

goto

写过汇编的人都知道，汇编改变指令执行地址的方法里，除了call/ret，还有大量的jmp/sjmp来构成一个程序，如果仅仅使用call/ret来写，有时候代码会变得非常臃肿，而且让本来就难以理解的汇编变成更难阅读的代码，所以就会用jmp/sjmp来改变指令执行的地址。当然这只是抛砖引玉，在汇编里改变指令执行地址可不仅仅这两对指令，还有很多其他指令和方法。

而goto是我在学c语言的时候接触到的，c++也依然部分支持（具体看编译器和相应语言标准）。goto更像是汇编中变成思维的一种移植，类*inx系统的内核代码里也拥有大量的goto使用。

在面向过程变成里，使用goto似乎并没有太大不适，而且也能在一定程度上减少代码规模。但goto若用的不好，带来的效果适得其反。而且容易使得代码逻辑变得极其复杂，非常的绕思维。

goto在短小精干的代码里，可以较少的带来阅读和易错现象，而且要把goto用的好，用的巧妙，还非常考验写代码的人如何编排代码流程和排版。

若没有过硬的逻辑思维能力和计算机式的思维能力，goto能避免最好避免，尤其是在写一些对代码体积和性能要求不是太高的情况下。

代码的性能和体积其实可以通过其它方式优化，未必非要这样。

递归

在数据结构和一些基本算法的教学里，递归是用的最频繁的。因为一些解题思路用递归来执行比较接近人类的思维方式，更容易理解。

栈帧的维护和执行，也是通过递归的方式进行的；可见递归的重要性。但是递归还存在容易让栈空间溢出，以及无限递归的出现，同样也存在一些不便于理解代码的情况。因为每一次递归函数的重入，都会使用新的栈帧对象，导致局部变量不是同一个的现象，这恰恰很有可能会让人在无意间错会递归的过程。

若不是解决问题的模型比较接近递归或代码短小精干的情况下，能用别的方式化解递归，最好通过其它方式。

状态机

状态机是一个基本的原型机或记录器，要从时间的角度出发讨论，状态机应该最先出现在高频模拟电路里，一些信号同步机制与触发应该是最接近状态机思维。

只不过后面称做状态机的都是从数字电路开始，状态机在设计门电路时，是最好用的一种分析工具或辅助工具。但在协议栈、驱动、直接和硬件交互的代码里，往往有着很多的状态机。

状态机由于仅仅是表征一种状态跃迁并联系成一个系统的工具，并未对状态跃迁的规则做约束，因此状态机很有可能会被设计的非常复杂，详情可以参考协议栈代码。若是过于强调状态机的特性，在写一些复杂度较高的策略模型时，往往是容易简单问题复杂化，甚至力不从心。

建议将状态机解耦，改为状态化就好。接触每种一状态之间的耦合度，会让代码较为简单些，如非常强调性能，可以通过其它方式解决。