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

这两天一直做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 态度
这两天看代码，总结就是如下：
前人拉屎，后人擦屁。
你不想擦屁吧，那么不要到处。。。。。。。

总结的很有道理啊，有些变量或方法的命名和它本身想表达的意义相差十万八千里，唉

1. 态度
2. Java编码规范
3. 优秀的源码例子 Junit等

现在很多程序员都很浮躁，从来不会想：这个代码为什么要这样写。
当然了，很多程序员都是为了混口饭吃，根本没有钻研的心态，唉！

说的很有道理啊，这两天看别人写的代码。。。产生同感啊

老生常谈之如何赚到钱，代码好不好我实在无力关心

任务多，时间紧。
哎！！！

junit的源码很好吗？看看去

Thanks！

总结的非常棒啊
自己的一点想法，打算尝试下：
对于命名一直在纠结中，取名太费时间了
A 通用命名规则大家都差不多
B 从Action到用户这一端，直接使用汉语拼音命名！
C 用户的数据表，表名和字段也用汉语拼音

这样客户和英语不好的都可以看懂。

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