8.5w+
社区成员
64.0w+
社区内容
- 主页
...全文
yizhixiaozhu 2005年03月22日
能赚到钱的就是好代码
xiaohezhiliu 2005年03月22日
无利不起早!!!
noyester 2005年03月09日
我朋友说别人看不懂的代码，才叫好代码，因为他牛。
slag 2005年03月09日
建议楼主看看《重构》
xiaohezhiliu 2005年03月09日
up
fengyecsdn 2005年03月03日
要看具体要求的
在不同地方 优秀的概念不一样啊
在不同地方 优秀的概念不一样啊
tengxiang05 2005年03月03日
study
pgfun 2005年03月03日
个人总结的几点标准：
*.不依赖注释来说明代码。以小弟的经验看来，代码的注释多往往是因为结构不清晰、难以理解。
优秀的代码本身就清晰易懂，注释只起到一个导读的作用。过分强调注释常常会使程序员
将使自己程序易懂易维护的责任推卸到一段段用于说明混乱的程序逻辑的混乱的注释上。
强调代码本身的清晰易读才是重点。
*.短小简明的函数，职能单一的对象。 前面有位老兄说“函数不得超过100行”，
按我说，当年面向过程的年代是这样，但到了如今面向对象的年代，超过20行的函数
就应当仔细考虑是不是应当将之拆分重构了。
*.代码的各类命名中大量使用设计模式词汇
*.很少的Case语句和逻辑判断语句。通过对象机制包装逻辑，而不是将逻辑毫无
组织地列出。在大多数情况下，大量出现case语句和if else语句的代码都不是
优秀的代码。同理，一个函数内两层以上的循环嵌套也是不好的。
*.简单为美，没有不必要的事先抽象，同时也没有重复的逻辑代码和设计
*.不依赖注释来说明代码。以小弟的经验看来，代码的注释多往往是因为结构不清晰、难以理解。
优秀的代码本身就清晰易懂，注释只起到一个导读的作用。过分强调注释常常会使程序员
将使自己程序易懂易维护的责任推卸到一段段用于说明混乱的程序逻辑的混乱的注释上。
强调代码本身的清晰易读才是重点。
*.短小简明的函数，职能单一的对象。 前面有位老兄说“函数不得超过100行”，
按我说，当年面向过程的年代是这样，但到了如今面向对象的年代，超过20行的函数
就应当仔细考虑是不是应当将之拆分重构了。
*.代码的各类命名中大量使用设计模式词汇
*.很少的Case语句和逻辑判断语句。通过对象机制包装逻辑，而不是将逻辑毫无
组织地列出。在大多数情况下，大量出现case语句和if else语句的代码都不是
优秀的代码。同理，一个函数内两层以上的循环嵌套也是不好的。
*.简单为美，没有不必要的事先抽象，同时也没有重复的逻辑代码和设计
seo2002 2005年03月03日
应该是能挣到钱的代码都是优秀的。
tmeteor 2005年03月03日
推荐一本书，asp.net组件编程,台湾人编的书，你可以看一下好的代码是什么样子
xixigongzhu 2005年03月03日
简单
maksim_wei 2005年03月03日
一个牛人告诉我的原则是“清晰”
zr1982930 2005年03月03日
优秀的代码，是人民大众能很Easy看懂的代码！
xiaohezhiliu 2005年03月02日
up
aceouter 2005年02月26日
优秀的代码是由有经验的程序员慢慢积累出来的。
xiaohezhiliu 2005年02月25日
what ?
程序的色彩 2005年02月06日
同意楼上朋友的观念.
console.write("最优秀的代码不值钱\n");
console.write("最优秀的代码不值钱\n");
zr1982930 2005年02月06日
其他人能够很容易看懂的代码！
Jackile 2005年02月06日
1.基本要求
1.1 程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2 打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3 尽量使用标准库函数和公共函数。
1.4 不要随意定义全局变量，尽量使用局部变量。
1.5 使用括号以避免二义性。
2.可读性要求
2.1 可读性第一，效率第二。
2.2 保持注释与代码完全一致。
2.3 每个源程序文件，都有文件头说明，说明规格见规范。
2.4 每个函数，都有函数头说明，说明规格见规范。
2.5 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7 常量定义（DEFINE）有相应说明。
2.8 处理过程的每个阶段都有相关注释说明。
2.9 在典型算法前都有注释。
2.10 利用缩进显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为6个字节。
2.11 循环、分支层次不要超过五层。
2.12 注释可以与语句在同一行，也可以在上行。
2.13 空行和空白字符也是一种特殊注释。
2.14 一目了然的语句不加注释。
2.15 注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16 注释行数（不包括程序头和函数头说明部份）应占总行数的 1/5 到 1/3 。
3. 结构化要求
3.1 禁止出现两条等价的支路。
3.2 禁止GOTO语句。
3.3 用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4 用 CASE 实现多路分支。
3.5 避免从循环引出多个出口。
3.6 函数只有一个出口。
3.7 不使用条件赋值语句。
3.8 避免不必要的分支。
3.9 不要轻易用条件分支去替换逻辑表达式。
4. 正确性与容错性要求
4.1 程序首先是正确，其次是优美
4.2 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4 所有变量在调用前必须被初始化。
4.5 对所有的用户输入，必须进行合法性检查。
4.6 不要比较浮点数的相等，如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
4.8 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。
5. 可重用性要求
5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2 公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3 公共控件或类应建立使用模板。
8错..支持
1.1 程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2 打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3 尽量使用标准库函数和公共函数。
1.4 不要随意定义全局变量，尽量使用局部变量。
1.5 使用括号以避免二义性。
2.可读性要求
2.1 可读性第一，效率第二。
2.2 保持注释与代码完全一致。
2.3 每个源程序文件，都有文件头说明，说明规格见规范。
2.4 每个函数，都有函数头说明，说明规格见规范。
2.5 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7 常量定义（DEFINE）有相应说明。
2.8 处理过程的每个阶段都有相关注释说明。
2.9 在典型算法前都有注释。
2.10 利用缩进显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为6个字节。
2.11 循环、分支层次不要超过五层。
2.12 注释可以与语句在同一行，也可以在上行。
2.13 空行和空白字符也是一种特殊注释。
2.14 一目了然的语句不加注释。
2.15 注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16 注释行数（不包括程序头和函数头说明部份）应占总行数的 1/5 到 1/3 。
3. 结构化要求
3.1 禁止出现两条等价的支路。
3.2 禁止GOTO语句。
3.3 用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4 用 CASE 实现多路分支。
3.5 避免从循环引出多个出口。
3.6 函数只有一个出口。
3.7 不使用条件赋值语句。
3.8 避免不必要的分支。
3.9 不要轻易用条件分支去替换逻辑表达式。
4. 正确性与容错性要求
4.1 程序首先是正确，其次是优美
4.2 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4 所有变量在调用前必须被初始化。
4.5 对所有的用户输入，必须进行合法性检查。
4.6 不要比较浮点数的相等，如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
4.8 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。
5. 可重用性要求
5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2 公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3 公共控件或类应建立使用模板。
8错..支持
godwater8 2005年02月06日
AhBian(阿扁)，同感
还是去外企好
还是去外企好