效率基本不用考虑了，应用层的东西谁还用C来写那绝对是脑子被门夹了:D

只会C、bash脚本、arm汇编的土豹飘过

脚本的那种变量类型其实有时候反而容易坏事，写多了就觉得这样太随意了很不踏实。不过脚本非常容易调试，对初学者来说是很大的优点

其实我所掌握的语言中最优雅精简的是arm汇编，而且一定是arm这类risc的指令，不能是x86类的cisc。32位risc短短一条32位对齐的指令里能做好几件事，十分内涵，充分发挥流水线效率；cisc的非等长指令就庸俗得多了。还有一直想不通C语言里为什么没有swp或xchg这样的instruction，汇编里明明是现成的

汇编里是用jump、branch来实现循环的，判断状态寄存器的值来跳转

顺便说下，C里面的goto虽然用来做循环是很操蛋，但goto并非一无是处，恰恰相反这是一种很有效率的编码风格，在C里用goto的无一例外都是老手，因为新手通常被告知goto是禁用的

[ 本帖最后由 henvelleng 于 2008-4-20 02:37 编辑 ]

只有在不在乎性能的应用层，性能才由编译器来决定，底层的东西全部都要自己掌握，包括最基本的库函数，绝不可能去用glibc这种加了N层防呆设计的东西，必要时连malloc都要自己重写。汇编这种东西在绝大部分使用场合并不是出于执行效率的考虑，而是C无法接触到CPU内部的寄存器，或是栈根本还没有建立

代码可读性个人认为90％取决于coder的水平，当然前提是阅读代码的人本身要有起码的架构常识。goto的问题是破坏程序结构，但是用得好，反而可以提高代码可读性，linux kernel里多得是goto，什么东西都不能一棍子打死的

代码可读性主要体现在结构和思想上面，诚然很多老手不喜欢写注释是有装B之嫌，但是这不影响其代码本身的优美

很多开源的代码写得是很差很业余的，这是开源的一个很大的弊病，不要以为写得人真有多牛B，我看根本就是业余爱好者写的，甚至是一路调试凑出来的代码毫无逻辑可言。说道老手装B，确实还有一种，那就是用很生僻的语法，比如＃＃之类

等……等等，我可没说开源代码质量不行啊，kernel代码都有非常严格的审核的，sourceforge同样也有审核，不过那个比较松，只要你的代码比较规范漂亮，申请一个project只要1－2天就能批，快得甚至1天之内，这么短时间很显然人家是不可能看完的

kernel的架构是一帮老鸟写的，具体历史不清楚。至于一些开源代码不行，除了一些是写的时候就差，有一些也是维护的问题。比如u-boot，显然很多代码是给其他人改得面目全非的，一看就是测试代码，都没去整理一下。唯一值得称道的mtd层，也是照搬kernel的，函数名什么的全部一模一样

代码的可读性和效率并不冲突，项目肯定要分层的，再业余的程序员也不可能在应用层跳过中间的抽象层直接调底层驱动的接口（其实我还真见过）。也就是说，无论项目多么庞大复杂，只要最初设计的架构足够出色或者说合格，就不会乱，沟通协商的部分早在架构设计时就得解决掉了

至于缩进、命名规则之类的细节问题，不是大问题，本身各自的区别肯定很小，各人保留自己的习惯没事，各个公司规范还不一样呢。如果你代码里出现类似magic number、滥用heap之类的问题，那这根本就不是什么coding style。能力差的可以做做测试，打打包什么的，真写了什么代码，也得由团队里的老手把关才行啊

缩进当有效字符其实也没啥的，makefile里也是这鸟样，吐啊吐啊 也就习惯了

真牛人在30岁前早就离开公司了，因为在公司里太限制个人发展了