资讯频道 → 研发管理
阅读更多

33顶
5踩

研发管理

翻译新闻 优秀的程序 vs. 糟糕的程序

2012-11-19 15:50 by 副主编 wangguo 评论(75) 有21150人浏览
编程 经验 项目
开发者Rahul Singh近日在其个人博客中列出了他眼中的优秀的程序和糟糕的程序：

引用
优秀的程序可以使复杂的东西看起来很简单；糟糕的程序让原本简单的东西变得复杂。

优秀的程序不需要加以说明；糟糕的程序需要大量注释。

优秀的程序编写时需要更多时间，但未来花费的时间却更少；糟糕的程序往往花费较少的时间，但会在未来浪费掉更多时间。

优秀的程序需要考虑当前和未来的需求；糟糕的程序只侧重于现在，在未来可能无法正常工作。

优秀的程序非常易于维护；糟糕的程序难以维护。

优秀的程序有更长的生命周期，甚至应用范围超出预期；糟糕的程序在其工作范围之外几乎无法使用。

优秀的程序如同良好的习惯，其影响将持续很长一段时间，几乎可以永久地解决问题；糟糕的程序如同止痛药，其效果只有很短的时间，解决问题大多是暂时的。

优秀的程序是整洁的、遵守规律的；糟糕的程序是混乱的。

优秀的程序可以令人学到很多编程方法和经验；糟糕的程序只能令人越学越糟。

优秀的程序中，该重用的地方重用，该发明的地方发明；糟糕的程序会重新发明轮子，并在适合发明的地方重用。

优秀的程序依靠程序员的直觉和知识，并经过了多年良好程序习惯的熏陶；糟糕的程序往往盲目依赖他人的知识和经验，而没有自己的理解。

优秀的程序可以很容易地从一个程序员转移给另一个程序员；糟糕的程序只能被编写者理解和实施。

优秀的程序员不会刻意去记忆一段代码，他依赖于他的逻辑思维能力和理解，并能在未来轻松改善代码；糟糕的程序员往往会记住很多自己不理解的代码。

优秀的程序都有相同的特征，如简单、可读性强、效率高；糟糕的程序各有糟糕之处。

优秀的程序比程序员存在的时间要更久；糟糕的程序存在的时间很短。


英文原文：Good Programming, Bad Programming

相关阅读：优秀的开发者 vs. 差的开发者
33
顶
5
踩
评论 共 75 条 请登录后发表评论
35 楼 if(i!=我){} 2012-11-21 10:34
z276356445t 写道
if(i!=我){} 写道
ewth126 写道
wxyzyu 写道
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。

对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。

笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！

之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。

永远记住一句话：设计大于实现，规则大于编码——远大于！

是吗？估计你那个类里边只是一些简单的业务逻辑处理吧，如果你要写一个框架或者抽取一些公用的模块出来，或者说你编写的代码移交给新手，请问你的代码该怎么来维护呢？写代码一直都要养成一个好的习惯，不管是写注释还是设计。况且在《重构》中提到，好的代码在一个方法中不应该超过50行代码。


批量更新采集数据：生产库中有重复的（重复2-8次，不定）、有信息不全的、有中间库有的生产库没有的、有生产库中有中间库没有的；修改时牵涉1张表，新增时牵涉4张表，要求返回统计信息、做好中间库标记。
这个业务还可以吧？告诉我，你准备用几个方法？
34 楼 kidneyball 2012-11-21 10:18
z276356445t 写道
if(i!=我){} 写道
ewth126 写道
wxyzyu 写道
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。

对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。

笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！

之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。

永远记住一句话：设计大于实现，规则大于编码——远大于！

是吗？估计你那个类里边只是一些简单的业务逻辑处理吧，如果你要写一个框架或者抽取一些公用的模块出来，或者说你编写的代码移交给新手，请问你的代码该怎么来维护呢？写代码一直都要养成一个好的习惯，不管是写注释还是设计。况且在《重构》中提到，好的代码在一个方法中不应该超过50行代码。


新手喜欢注释是因为：1. 注释比程序容易看（自然语言，多亲切）；2.自以为如果因为注释出错导致自己浪费时间，不关他事（虽然通常顶头上司不会这样看）。 新手最喜欢干的事情，就是把一整个方法连同注释从这里复制到那里，然后把方法名字改掉，把方法里四分三的代码改掉，注释一个字都不动。
33 楼 z276356445t 2012-11-21 09:56
if(i!=我){} 写道
ewth126 写道
wxyzyu 写道
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。

对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。

笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！

之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。

永远记住一句话：设计大于实现，规则大于编码——远大于！

是吗？估计你那个类里边只是一些简单的业务逻辑处理吧，如果你要写一个框架或者抽取一些公用的模块出来，或者说你编写的代码移交给新手，请问你的代码该怎么来维护呢？写代码一直都要养成一个好的习惯，不管是写注释还是设计。况且在《重构》中提到，好的代码在一个方法中不应该超过50行代码。
32 楼 ray_linn 2012-11-21 09:54
我觉得linux内核的程序就很糟糕。。
31 楼 if(i!=我){} 2012-11-21 09:33
ewth126 写道
wxyzyu 写道
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。

对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。

笑话！注释的重要性大于代码？还远大于？还有上上一层的“3000多行的代码”，更是个笑话！

之前接过一个做一半的项目，最大一个类2000多行、一个方法300多行，各种标识，各种重复。最后业务层我删了1/2代码，而且完成了更多的功能。没怎么加注释，但没人敢说他看不懂。

永远记住一句话：设计大于实现，规则大于编码——远大于！
30 楼 kidneyball 2012-11-21 09:25
那些看着在私有方法或者方法内部上的注释来维护代码的朋友，有一个事情我实在想不通，你看到一堆你看得懂的注释，后面跟着一堆你看不懂或者不想认真看的代码，你怎么能确定这段注释与后面的代码同步呢？如果你对一堆你参照着注释来看才勉强看懂的代码做了小许修改，有多少机会你会回过头去认真修改注释。就算你自觉性强，你能保证身边多少人有这样的自觉性。个人觉得私有方法或方法内部的注释只有以下几种是有价值的：
1. TODO和FIXME
2. 在一些非常规的做法上说明为什么没有采用常规做法（以防后面忘了原因，又改回常规方法了）
3. 在临时注释掉的代码之前说明为什么要注释掉

其他在主线流程上的注释，看了不如不看。

有人说，那我想说明某段代码对应哪个业务需求怎么办。正确做法是，每次只提交跟某个业务需求相关的修改，认真写好提交信息，这样从版本控制的Annotation上就能清清楚楚看到每一行代码时对应哪个需求的。
29 楼 qq672076266 2012-11-21 09:17
从后期维护的角度，简洁明了的注释还是要有的
28 楼 kidneyball 2012-11-21 08:40
phk070832 写道
小鱼不爱水 写道
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.

这是要干什么啊？几千行的类？COBOL吗？

需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。


解决问题的时候，如果操作得当（由异常位置反推），怎么会跑到无关的地方去。如果你跟着逻辑链跑到一个类里，一看注释，嗯，跟要解决的问题无关，不看。查了一天发现问题就在这里，再排查半天，某人跟你道个谦：哦，不好意思，改了程序忘了改注释。你找谁哭去。
27 楼 ewth126 2012-11-20 23:12
wxyzyu 写道
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。

对的，我觉得注释的重要性远大于代码，毕竟你不能保证你写的代码以后的效率依然是最高。大家都让别人方便，自然维护就方便了。
26 楼 wxyzyu 2012-11-20 22:07
就算一切都符合规范。但是万一有很深的一层的代码逻辑有一点点错呢？
25 楼 wxyzyu 2012-11-20 22:04
ewth126 写道
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
我觉得注释真的很重要。试想3000多行的代码的一个类没有注释。后来修改的人怎么做？再加上偶尔strTemp这种蛋疼的全局变量。
24 楼 ewth126 2012-11-20 15:19
注释还是要把，到时候生成说明什么的更加方便！你的程序不能只是为了让懂的人看懂，还要让后辈们，或者是在学习中的人看懂，程序员是一种传承。
23 楼 wlxlz 2012-11-20 13:43
糟糕的程序甚至连注释都没有
22 楼 nail2008 2012-11-20 13:39
好代码不需要注释“程序行为”，但是不代表不需要注释“为什么这么做？”。
个人认为业务场景还要要说明的。
而且这篇明显就是老外写的，英语是人家的母语，我们很多程序员命名都是金山词霸出来了，词不达意，或者歧义的情况时有发生，该写注释的时候还是要写的。
21 楼 phk070832 2012-11-20 13:10
小鱼不爱水 写道
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.

这是要干什么啊？几千行的类？COBOL吗？

需要几千行吗？假设有一段50行的代码，如果根据注释发现这段代码跟你需要解决的问题无关，你就完全可以跳过，这样你每次看代码都可以节省时间。
20 楼 小鱼不爱水 2012-11-20 12:56
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.

这是要干什么啊？几千行的类？COBOL吗？
19 楼 phk070832 2012-11-20 12:20
Mybeautiful 写道
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.

个人认同优秀的程序不需要注释，如果代码沦落到需要注释了，说明有极大地改善空间；正如你看一本故事会，还还翻字典才懂故事说的是啥，这样的故事估计不是好故事。


优秀的程序绝对需要注释：
1.有注释的代码看起来决定不会比没注释的代码慢（如果你觉得不是这样，那你完全可以忽略注释，这样也就符合我这个理由）
2.我觉得lz对注释的理解太狭隘了，注释不只是名词解释或者语法解释，还可以是逻辑实现概况，如某一段代码干了什么，某个方法干了什么...，这样在找代码时可以跳过很多无关的代码；而且你完全可以把你写代码时的思想、可以进一步进行改进的想法以及需要注意的方面写到注释里；......
18 楼 qianhd 2012-11-20 11:50
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.


那只能说没多少程序员是正常的.
17 楼 少城SC 2012-11-20 11:23
程序员要多学习，多看看别人的代码，不能闭门造车
16 楼 Mybeautiful 2012-11-20 11:03
elektrobank 写道
if(i!=我){} 写道
Frankie199 写道
“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

恰恰相反


我非常认同“优秀的程序不需要加以说明；糟糕的程序需要大量注释。”

如果一段代码：
变量命名规范
方法名见名知意
方法粒度合适（功能专一、健壮）
格式化良好

我认为是不需要注释的，至少在方法内部是不需要注释的。除非读者的英语水平很差、或者没学过编程。



您说得内几点, 是个正常点的程序员都做得到. 注释的目的是让人家看懂整个过程中如何处理或实现复杂的业务逻辑.

个人认同优秀的程序不需要注释，如果代码沦落到需要注释了，说明有极大地改善空间；正如你看一本故事会，还还翻字典才懂故事说的是啥，这样的故事估计不是好故事。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • JVM类装载器详解

    JVM类装载器详解

  • JVM类装载器机制

    加载：查找并加载类全限定名的二进制字节流，转为方法区数据结构（特殊的堆），在Java堆中生成对应的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。 注意：对于数组类，情况就有所不同，数组类本身不...

  • java类验证和装载顺序_一张图看懂JVM之类装载系统

    原标题：一张图看懂JVM之类装载系统 导读在之前的文章中，我们通过一张图的方式(图????)整体上了解了JVM的结构，并重点讲解了JVM的内存结构、内存回收算法及回收器方面的知识。收到了不少读者朋友们的反馈和指正，在...

  • JVM类加载器（类装载子系统）

    加载:通过类的全限定名获取此类的字节流,将流代表的静态存储结构转化为方法区(作为一个内存区域,jdk1.7以前永久代,1.8之后元空间)的运行时数据结构,在内存中生成一个代表该类的java.lang.class对象,作为方法区这个类...

  • JVM之类装载子系统

    如果一个类是用户类加载器加载的，JVM会将类加载器的引用作为类的一部分信息保存在方法区当中，当解析一个类型到另一个类型引用的时候，JVM则必须保证两个类加载器是相同的。（动态链接） JVM中对类的使用分为主动和...

  • JVM系列之三：类装载器子系统

    　虚拟机类装载器子系统：虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。 　类的加载指的是将类的.class文件中的二进制数据读入到...

  • JVM类加载器子系统

    JVM Class Loader SubSystem概述类加载的过程加载阶段(Loading)链接阶段(Linking)初始化阶段(Initialization)3种类加载器& 自定义加载器获取 ClassLoader的4种方式自定义类加载器(User Defined ClassLoader)双亲...

  • JVM学习笔记02-类加载器子系统

    1、类加载器子系统的作用 2、类加载器ClassLoader角色 3、类的加载过程 3.1、加载 3.2、链接 4、类加载器的分类 4.1、引导类加载器（Bootstrap ClassLoader） 4.2、扩展类加载器（Extension Class Loader） ...

  • JVM(二)类装载子系统

    类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine(执行引擎)决定。 加载的类信息存放于...

  • JVM—类加载子系统

    类加载器执行引擎在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。为什么要自定义类加载器？隔离加载类修改类加载的方式...

  • JVM类加载子系统

    类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine(执行引擎)决定。 加载的类信息存放于...

  • [JVM]超详细JVM系列文（1）：整体结构+类加载子系统+运行时数据区—程序计数器、栈（多图长文）

    按照Java代码执行的流程，从类装载器子系统出发，剖析其各个子模块的结构与功能。结合Java语言中的相关设计思路（变量的初始化、存储；对象的生命周期、方法的调用）、OOP（继承、多态），在JVM进行追根溯源，解释其...

  • JVM一：类加载器子系统

    类加载器子系统（ClassLoader）：将class字节码文件加载到JVM内存中,是否会执行该字节码文件由 执行引擎决定。 类加载器子系统（Class loader subSystem）只负责将class文件加载进内存中，并且类在仅需要时加载，...

  • 【JVM】VM是什么？JVM是什么？JVM作用是什么？JVM特点？JVM位置？JVM组成？

    1、类加载子系统类加载的角色？类加载的过程？① 加载 Loading② 链接 Linking③ 初始化 Initialization类什么时候初始化？类的初始化顺序？类加载器分类？双亲委派机制是什么？双亲委派的优点？类的主动使用/被动...

  • JVM第二章-类加载子系统

    类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。 加载

  • JVM-类加载子系统

    System . out . println("你的大恩大德，我下辈子再报！");} }它的加载过程是怎么样的呢?...完成后调用 HelloLoader 类中的静态方法 main加载失败则抛出异常完整流程JVM严格来讲支持两种类型的类加载器。...

  • JVM总结之类加载子系统

    一个类的完整生命周期如下 类加载过程 Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？ 系统加载 Class 类型的文件主要三步：加载->连接->初始化。连接过程又...

  • JVM系列之类加载子系统

    1、类加载器与类的加载过程 1.1、类加载器 1.1.1、类加载器子系统的作用 负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识，魔术，CA FA BA BE Classloader只负责class文件的加载，...

  • 4. JVM-类加载子系统

    类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。 加载的类信息存放于一块称为...

  • 【JVM】类加载子系统

    一，内存结构 二，类加载器及类加载过程 三，类加载器的分类 四，ClassLoader的常用方法及获取方式 五，双亲委派机制 六，其他

Global site tag (gtag.js) - Google Analytics