大家倾向于哪种编程风格
最近在看某opencv的源代码，发现代码的编写者非常注重程序的效率，经常把一些逻辑上不相关的程序写在一起，以减少程序的循环次数，但是却降低了程序的可读性，也使得程序没法被分解成更多小的模块，只能在一个比较长的函数中顺序执行。
我想请教大家，这种做法是否值得借鉴呢？还是应该按照逻辑，将程序写成一个函数调用另外一个函数，但是每个函数都不是很长的方式。我个人比较倾向于这种做法，因为很多算法逻辑上本身就很复杂，如果再将它写的支离破碎，就更令人头疼了。
希望大家踊跃发言！
[解决办法]
先写简明的，用一堆小函数构成稳定的程序；
然后提高运行效率，改合并的合并，改重写的重写。
[解决办法]
主要看程序需要什么了，如果极端需要效率，连汇编都会用上。
[解决办法]
不值得学习。
[解决办法]
代码简洁可读性才是首选。
[解决办法]
我也觉得可读性才是最重要 写那种不相关的代码 自己回来阅读都很困难 更不用说别人了
[解决办法]
楼主啊，你是在做opencv么？如果不是几乎完全相同的约束条件，那模仿它就是作茧自缚。
[解决办法]
两者都很重要，如果能找到一种折中的方式，不失为一种很好的手段。
我个人的看法是，效率不是差距很大的情况下，简介性要考虑的。
效率优先，兼顾简洁。
[解决办法]
个人觉得简洁的好，不过也许我也没写过非常要效率的代码吧，不过我听说某些要效率的代码会嵌入脚本或是汇编的。
[解决办法]
我觉得：如果真是需要效率至上的应用，当然需要更高效的代码。
否则效率都不满足，代码再好看也无用。
其它地方自然不必因为效率而写出非常难懂的代码。
[解决办法]
程序的可读性，放首位。
效率是看不見的東西，
你想到的效率未必真的就是效率問題，
確實有證據了，再來解決它。
有句話好像是這麽說的，過早的優化是萬惡之源。
個人觀點，僅供參考。
[解决办法]
看你做什么样的项目了。如果你做的是像opencv这样的图像处理库，或者xvid这种视频编解码库，那就必须优先考虑效率问题。
不过就算是这种库，一般开发时也不是一开始就优化的，一般是先编出未优化的稳定版本，而然慢慢优化，该嵌汇编就嵌汇编。如果上来就写晦涩的代码，很影响开发效率。
[解决办法]
过早的优化是万恶之源!
[解决办法]
不要进行不成熟的优化。
[解决办法]
