老生常谈之如何写好的代码

这两天一直做code review，经常看着看着就有一种要死的冲动。
好的代码，一个老生常谈的问题。结合最近的实践，总结一下常见的问题。

1 了解你的代码
很多程序员并不了解自己的代码。
比如null!=Object，很多人已经不知道为什么会有这样一个编码规范，怕if(Object!=null)写成Object=null通过判断。我并不喜欢这个规范，因为读起来不自然。

2 不要盲从
一段程序catch一个RuntimeException，把这个RuntimeException封装成一个新的RuntimeException又抛出来，问他为什么这么做，他说上层的程序catch不到这个RuntimeException，要自己构建一个RuntimeException才能catch住。而且他还咨询了别人的意见，参考了其他的代码。
我问他这样合理吗，这样可以解决问题吗，一段程序catch不到原生的RuntimeException，凭什么就能catch住你封装又抛出的RuntimeException。他的最大理由是别人这么说，所以就这么做了。同学，坚持一下自己。你应该知道这是不可能的。
后来发现问题在于打日志的程序写错了，打的是原生的toString方法，所以导致他以为没有catch到异常。
别人的代码catch是为了加入一些自定义错误消息。

3 不要产生无用的对象
A a=new A();
if(condition){
  a=getAFrom();
}else{
  a=getAFrom();
}
这样的new有什么用，唯一的用处就是产生垃圾。

4 不要轻易怀疑类库，先怀疑自己
一段js返回一个日期的7天前的日期，结果多了一天。结果理由就是类库出错，需要java程序员计算该值，然后传入。
当然不能这么搞了，仔细研究了代码之后，发现是js写错了。

5 命名
这个基本所有的编程书都讲了，但是估计很多的程序员对这个东西并没有足够的重视。变量，方法，类的命名一定要想一些时间再命名，不要贪图一时之快。

6 去除重复代码
这个应该算是最著名的bad code smell了。但是看代码的时候还是会不时发现一大堆重复code。
该重构了，今天重构的时候就发现了一个简单的常量两处设置不一样，但是程序的内容和意义都是一样。如果这个拖到以后，又是一个坑。

7 遵循习惯
java的实例变量的默认值大家都是知道的。请不要在一个有20-30个实例变量的类中，突然有一个boolean设成true。我一般一看这么多的实例变量，都是默认认为它们的初始值是java默认初始值。当然，一个类本身有20-30实例变量本身就是一个很扯的事情。

8 不要无用的代码
系统总是有一些历史原因，永远不会执行到的代码，发现了就删掉吧。程序员已经很辛苦了，不要让大家把时间浪费在没有用的事情上。而且，这个东西，很有可能引起读着对程序的误读。

9 没有小事
别催了。让我专业的写程序，哪怕你觉的只是加一个变量的问题，我还有很多东西需要考虑呢。这个变量加在什么地方，叫什么名字，什么类型，如何使用，测试怎么办。一大堆问题等着我呢。

10 态度
这两天看代码，总结就是如下：
前人拉屎，后人擦屁。
你不想擦屁吧，那么不要到处。。。。。。。

评论

72 楼 awdxzc 2010-11-25  

public class 我的第一个汉字类 {

private static String 姓名= "感恩节快乐,happy!";
public static void main(String[] args) {
打印(姓名);
}

private static void 打印(String str)
{
System.err.println(str);
}

}

71 楼 zhang_xzhi_xjtu 2010-11-18  

注意 我讨论的java 当然知道这个问题的原由了

70 楼 liuyupy 2010-11-18  

关于第一点,请参照C++编程习惯..

69 楼 twdj217 2010-11-13  

深有同感，我就很不喜欢命名乱起的代码，与这样的同事一起工作时，经常为了搞明白他写的变量名称指代什么而浪费时间，不规范的命名以及书写格式，在团队开发时体现出来的弊端尤为明显

68 楼 sling2007 2010-11-12  

变量问题  深有体会啊

还有一个问题是：注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释注释

67 楼 zhang_xzhi_xjtu 2010-11-09  

项目都是前面技术比较好的人开发完之后丢给后面的人擦屁股
从这个就没有觉得是什么技术好的人。

66 楼 yaojialing 2010-11-09  

paranoid945 写道

很多情况老板只是让你搥出一个看上去好看能用的东西然后最大化赚钱而已。要不然为啥那么喜欢雇工资才2，3k的程序员，何况大多数的项目都是靠着第一波比较厉害的程序员，然后再找理由搞掉他们，换一批低廉的程序员擦屁股...
很多情况是很搞笑的，比如有好些人特意不写注释，为的就是让这块代码只有自己懂，然后别人搞不定只能找他。中国人自古就没有牺牲奉献精神，从不会做“前人栽树，后人乘凉”的事情，而是做“前人砍树，后人的事情跟我就没有关系了”

前面一段话我赞同，后面的我反对。  我们公司就都是些新手，项目都是前面技术比较好的人开发完之后丢给后面的人擦屁股，我就接了这么个擦屁股的项目，但我那时不是新手，也不是高手。自己写程序的时候也会想很多事情，比较难懂的地方我都会写注释，也考虑后面维护的人是否能看得懂才加的。做人要厚道，做程序员也要厚道。都是写代码的，换位思考一下就会深有体会

65 楼 xchao 2010-11-09  

不错，要是一个团队的全部成员都能意识到这些问题，那该有多好，

这样就有一个统一的交流起点了！

只可惜我们的团队总是参差不齐`

64 楼 抛出异常的爱 2010-11-08  

mmwy 写道

tuti 写道

不要那么悲观吗
你可能资深，知道这些东西，别人可能这方面还不了解。
大家沟通一下，做做code review（这也是个惯用法）,这个问题就解决了。
写程序的XDJM，基本上人品都不错的,不用顾虑太多。

以前看过一段话，说是同一段业务，普通程序员花70％的量做业务，30％的代码修栏杆。而老程序员是业务代码占30％，剩下70％的代码都在修栏杆。

够狠直接exit 0

63 楼 mmwy 2010-11-08  

tuti 写道

不要那么悲观吗
你可能资深，知道这些东西，别人可能这方面还不了解。
大家沟通一下，做做code review（这也是个惯用法）,这个问题就解决了。
写程序的XDJM，基本上人品都不错的,不用顾虑太多。

以前看过一段话，说是同一段业务，普通程序员花70％的量做业务，30％的代码修栏杆。而老程序员是业务代码占30％，剩下70％的代码都在修栏杆。

62 楼 tuti 2010-11-08  

mmwy 写道

判断null也是没办法的事情，总是有些人的接口并不返回empty array，而是直接返回null
你的同伴总是不可靠的。

不要那么悲观吗
你可能资深，知道这些东西，别人可能这方面还不了解。
大家沟通一下，做做code review（这也是个惯用法）,这个问题就解决了。
写程序的XDJM，基本上人品都不错的,不用顾虑太多。

61 楼 mmwy 2010-11-08  

tuti 写道

其实到处判断容器类是否是null 也是个常见问题。
为什么不写“userList==null”，这牵扯出另外一个惯用法。

参见 《Effective Java》
Item 43: Return empty arrays or collections, not nulls

判断null也是没办法的事情，总是有些人的接口并不返回empty array，而是直接返回null

你的同伴总是不可靠的。

对DBA来说，程序员总是来搞破坏的，能让程序员调存储过程／视图就尽量不让他们来直接操作表。
对业务层来说，做前端的总是不干好事，能判断能封装的就一定要处理。

60 楼 tuti 2010-11-08  

mmwy 写道

tuti 写道

举个例子：
  很多人喜欢写 if (userList.size()==0){
                  ...
               }
  惯用法应该写成
              if (userList.isEmpty()){
                  ...
               }

还要考虑为空的情况，严谨一点写成

if ( userList==null || userList.isEmpty() ) {

}

其实到处判断容器类是否是null 也是个常见问题。
为什么不写“userList==null”，这牵扯出另外一个惯用法。

参见 《Effective Java》
Item 43: Return empty arrays or collections, not nulls

59 楼 mmwy 2010-11-08  

tuti 写道

举个例子：
  很多人喜欢写 if (userList.size()==0){
                  ...
               }
  惯用法应该写成
              if (userList.isEmpty()){
                  ...
               }

还要考虑为空的情况，严谨一点写成

if ( userList==null || userList.isEmpty() ) {

}

58 楼 likehibernate 2010-11-08  

这个可以算是中国软件业存在的一个很大的问题吧！
在中国，做行业软件的技术员由于行业要求大多数都转成做业务的了，真正有恒心做技术，把技术做好做精的，不多了！

57 楼 deng_1987 2010-11-08  

前人拉屎，后人擦屁。。在一个烂尾项目中深刻体会到了

56 楼 zhang_xzhi_xjtu 2010-11-08  

wzju64676266 写道

A a=new A();
if(condition){
  a=getAFrom();
}else{
  a=getAFrom();
}


虽然说new A();是脱了裤子放屁，但看你们怎么定义规范的，比如这段代码在biz层的一个方法中，并且return  a对象，有可能在执行getAForm的时候抛出exception了，这个时候可能没有给a实例赋值，平时写代码一个比较烦琐的事情就是判断null，这个时候在ui层的规范如果是尽量去除null判断，统一规定biz返回给ui层是非null


只要他们符合公司定义的规范就行了，但一个人写一种规范真是让人看得吐血

异常如果被捕获，则返回null是一个接口行为。
如果没有被捕获，则向上抛。

不论那种情况，这个new都是没有什么用的。

55 楼 wandou 2010-11-08  

其实所有的烂代码都只有一个原因：
外行管理内行。

54 楼 wzju64676266 2010-11-07  

A a=new A();
if(condition){
  a=getAFrom();
}else{
  a=getAFrom();
}


虽然说new A();是脱了裤子放屁，但看你们怎么定义规范的，比如这段代码在biz层的一个方法中，并且return  a对象，有可能在执行getAForm的时候抛出exception了，这个时候可能没有给a实例赋值，平时写代码一个比较烦琐的事情就是判断null，这个时候在ui层的规范如果是尽量去除null判断，统一规定biz返回给ui层是非null


只要他们符合公司定义的规范就行了，但一个人写一种规范真是让人看得吐血

53 楼 tntsuifeng 2010-11-07  

有的时候任务压的实在太紧了，很多事情都没有时间考虑到
当然这种情况只是对我们这种新手而言是这样的