还是写代码风格的问题，如果设计代码布局

再增加个问题， 返回类型为void的方法有什么意义？ 如果做一件事情，肯定要知道结果的，想不通

1 建议看看进攻型代码，可以尽量减少if else嵌套。

2 抛出异常也是一种返回结果，而且是一种更优秀的设计

从一开始就按着业务逻辑写代码。而不是实现逻辑写。
可能有帮助。

另外就是经常重构代码，从最简单的命名开始，好的命名可以有效的减少混乱。

有的函数确实不需要返回值啊，比如swap

@avatasia
1、在设计阶段尽量把你的东西切割开。
2、每个方法完成一个简单的任务。
3、设计好你的方法（函数）声明。

至于void，有时候更多的是达到目的的不同手段。

建议 import this 一下~~~

@avatasia 知道结果的方法有很多种，除了函数返回结果，还可以传入一个指针/引用，用于存取结果。
返回多个结果的函数似乎不是普遍存在的。

可以学习一下LISP，书里都有很好的函数式编程的风格介绍，如何设计函数式的程序等等。虽然一个应用程序做到纯函数式过于偏激了，但是对于一些核心逻辑，按照函数式的理念进行设计是很棒的。
按照LISP的风格写下来，整个程序似乎都变成了自制DSL的使用。
还有这个，
http://avdi.org/talks/confident-code-rubymidwest-2011/confident-code.html
How-to write Confident Code.

@zephyro @myrual @9hills @kojp @leiz @keakon @zicjin 返回异常不算是优秀设计把，我记得think in c++的作者说过，异常是一个很搞的东西，会降低性能。 我的意思是人在自然界里做什么事情都是要知道结果的，尤其是程序，没有返回，是不是意味着失去控制，失去控制意味着什么大家一定明白，就像swap,你swap的值肯定要用的，不用为什么要swap，如果交换失败怎么办？

@avatasia 你想太多。

没看过think in c++，但写过几年代码的我从来不觉得异常有什么好，或者性能问题，真有性能问题那也是框架设计的问题。
没有返回为什么不能算是一种结果？它代表一切正常的结果。
你纠结在这些字眼里还不如多写点大型架构切身体验一下。

@avatasia 返回是给其他部分代码用的，不是给自己用的

@zicjin 貌似这个就是大型架构的基础啊，例如windows消息机制，核心就是sendmessage postmessage,就算调用postmessage,那么这个postmessage的操作如何保证成功。

@avatasia swap是交换引用或指针，逻辑上不可能出现失败的情况……如果真的因为未知原因（例如CPU缺陷）而失败的话，你的返回值就不会因为这种未知原因而弄错么？

@keakon 分析一下swap吧， 假如swap出错，可能什么原因呢？ 内存占满，如果你中间使用了临时变量，这个临时变量没有stack分配内存，导致出错，那么你获得返回值，然后就可以进行出错处理，例如后面的操作不进行，输出日志，等待下一次继续运行。 我们平常为什么不考虑这些情况，那是因为我们的思维习惯都允许这种极限情况发生。

没有返回不意味着失去控制，或者说你为啥认为没有返回就失去控制了？
如果你担心交换失败，那还不如抛出异常，虽然我想象不出怎样失败，而且还是能返回返回值通告的那种失败。
另外语言有异。在Python里捕捉异常没有什么性能损失。

the art of readable code pdf文件 页数不多，很实用。

@avatasia 这个临时变量的大小是sizeof(void*)，优化情况下会是寄存器。函数调用时会分配足够多的栈空间（例如1MB），这是在编译期就由编译器保证的。更进一步，如果连sizeof(void*)的空闲内存都没有，当内存分配失败时，你如何获知失败并返回一个失败值？你根本没内存去捕捉异常哦。

"目前碰到的一个很严重的问题， 代码长了，改动的地方一多，就会忘掉某些东西，导致到处补漏"各个模块耦合太厉害了？考虑重构。

@avatasia @Mr_Vangogh 除了耦合厉害之外，还有一个可能是重复代码太多，没有做很好的抽象。

@avatasia swap都要加返回值～～～你这样写出来的程序会又臭又长的。。。

@9hills 确实. 以前有过尝试,太多的返回值判断,看上去非常恶心又没有必要.

@avatasia 如果全靠返回值，那么try catch就没有必要了。
我曾经就有一段时间，所有函数必须返回状态，绝对不用try catch，觉得效率底下。
现在没有这样了，返回值就应该是我期望的东西，异常统统throw，所以现在我很多控制ui的，非算法的function，都是不返回的。