zhang_xzhi_xjtu
- 浏览: 524475 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
飞天奔月：
public List<String> gener ...
实践中的重构30_不做油漆匠 -
在世界的中心呼喚愛：
在世界的中心呼喚愛 写道public class A {
...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛：
在世界的中心呼喚愛 写道在世界的中心呼喚愛 写道在classB ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛：
在世界的中心呼喚愛 写道在classB的finalize上打断 ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛：
iteye比较少上，如果可以的话，可以发e-mail交流：ch ...
深入理解ReferenceQueue GC finalize Reference
每当看到代码中有一个明显的冗余的时候，我就有一个感慨，这家伙时间真多啊，放个屁还要脱裤子。
看例子。
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。代码文件往下一拉，果不其然。
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
第一处的代码可以改为：
第二处的代码可以改为：
当然，这里addressCode对应的描述信息应该从配置文件里面读取比较好。但是由于不是本文关注的重点，不赘述。
代码风格问题
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
enum很爽，但1.4的JDK编译不通过！
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
switch 更好些，不过现在还没搞定string...
如果语法里默认含有break switch 也可以用用.....
有了break后太灵活了
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
switch 更好些，不过现在还没搞定string...
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
一堆if else或者 equals 好读，还是一个contains好读。
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
如果第一个就命中是if..else效率比较高，但是如果后面的命中，Map明显比if..else效率高
特地试了一下,排除异常的情况，每1,000,000此循环
if..else 根据命中几率递增，第一个最快15ms，第二个命中基本上与Map持平23ms，到第三个比Enum稍快31ms
Map 基本上保持在24ms左右
Enum 基本上在36ms左右
还没有来得及出性能测试呢，被仁兄抢先了。
同意，但是不是本文的关注点。
代码格式化一下看看。
1 同意，由于场景的实际情况，调用的时候最多的情况不为null，考虑情况不应该这么写。
2 不同意。api已经注明了是null safe。另，一个方法，如果你不相信它的某些条件或者前提，这个方法你就不应该调用。著名的例子就是2分搜索。2.0如果改动的话，因为涉及到接口定义的改动，应该新建一个方法。
addressCode如果为null的话，直接短路，至少可以减少一次方法调用啊
有些人处处都很注意性能，习惯问题，也没到脱裤子放屁那么严重
鉴于公司原因代码不能全部开放，考虑性能的话就不会这么写了，因为不为null的情况是最多的。
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
如果第一个就命中是if..else效率比较高，但是如果后面的命中，Map明显比if..else效率高
特地试了一下,排除异常的情况，每1,000,000此循环
if..else 根据命中几率递增，第一个最快15ms，第二个命中基本上与Map持平23ms，到第三个比Enum稍快31ms
Map 基本上保持在24ms左右
Enum 基本上在36ms左右
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
addressCode如果为null的话，直接短路，至少可以减少一次方法调用啊
有些人处处都很注意性能，习惯问题，也没到脱裤子放屁那么严重
看例子。
if (addressCode != null
&& (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN) || StringUtil
.equals(addressCode, OTHER))) {
// do something.
} else {
// do something.
}
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
if (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN)
|| StringUtil.equals(addressCode, OTHER)) {
// do something.
} else {
// do something.
}
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。代码文件往下一拉，果不其然。
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
}
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
}
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
}
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
}
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
第一处的代码可以改为：
if (addressMap.containsKey(addressCode)) {
// do something.
} else {
// do something.
}
第二处的代码可以改为：
if (addressMap.containsKey(addressCode)) {
return addressMap.get(addressCode);
}
当然，这里addressCode对应的描述信息应该从配置文件里面读取比较好。但是由于不是本文关注的重点，不赘述。
分享到：
评论
25 楼
lichuan
2011-03-19
代码风格问题
24 楼
ugibb510
2011-03-07
抛出异常的爱 写道
zhang_xzhi_xjtu 写道
抛出异常的爱 写道
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
enum很爽，但1.4的JDK编译不通过！
23 楼
抛出异常的爱
2011-03-07
mathgl 写道
抛出异常的爱 写道
zhang_xzhi_xjtu 写道
抛出异常的爱 写道
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
switch 更好些，不过现在还没搞定string...
如果语法里默认含有break switch 也可以用用.....
有了break后太灵活了
22 楼
aninfeel
2011-03-07
这种太平码在我们的项目太tmd常见了，如if(str!=null&&StringUtils.isNotEmpty(str))，还有一些验证之后再验证的，写代码的人明显是怕出事，宁可多判也不少判，只要程序不出错就行。这种人在程序界往往混得很好。而有代码洁癖的却常常出问题（一般都是调用别人的方法造成的），反而在boss面前显得不可靠。
21 楼
mathgl
2011-03-07
抛出异常的爱 写道
zhang_xzhi_xjtu 写道
抛出异常的爱 写道
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
switch 更好些，不过现在还没搞定string...
20 楼
volking
2011-03-05
一样脱裤子放.
19 楼
抛出异常的爱
2011-03-04
zhang_xzhi_xjtu 写道
抛出异常的爱 写道
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
一堆if else或者 equals 好读，还是一个contains好读。
enum更爽快一些....
hashmap还要put一堆东东好恶心
18 楼
zhang_xzhi_xjtu
2011-03-04
抛出异常的爱 写道
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
一堆if else或者 equals 好读，还是一个contains好读。
17 楼
抛出异常的爱
2011-03-04
去他的 扯淡的优化原则......
以好读为准...
以好读为准...
16 楼
zhang_xzhi_xjtu
2011-03-04
Ben.Sin 写道
buzhucele 写道
ak121077313 写道
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
如果第一个就命中是if..else效率比较高，但是如果后面的命中，Map明显比if..else效率高
package ben.test.performance.ifelse;
import java.util.HashMap;
import java.util.Map;
public class MapIfEnum {
public static final String HK = "HK";
public static final String MACAO = "MC";
public static final String TW = "TW";
public static final String OTHER = "OTHER";
public static void main(String[] args){
// String code = HK;
// String code = MACAO;
// String code = TW;
String code = OTHER;
MapIfEnum test = new MapIfEnum();
long start = 0L + System.currentTimeMillis();
for (int i = 0; i < 1000000; i ++){
test.useIfElse(code);
// test.useEnum(code);
// test.useMap(code);
}
long end = 0L + System.currentTimeMillis();
System.out.println("Used time = " + (end - start));
}
public String useIfElse(String code){
if (HK.equals(code)){
return "中国香港";
} else if (MACAO.equals(code)){
return "中国澳门";
} else if (TW.equals(code)){
return "中国台湾";
} else {
return "其他地区";
}
}
public String useEnum(String code){
return Area.valueOf(code).getDesc();
}
public String useMap(String code){
return areaMap.get(code);
}
enum Area{
HK("中国香港"),
MC("中国澳门"),
TW("中国台湾"),
OTHER("其他地区");
private String desc;
private Area(String desc){
this.desc = desc;
}
public String getDesc(){
return desc;
}
}
public static Map<String, String> areaMap = new HashMap<String, String>();
static {
areaMap.put("HK", "中国香港");
areaMap.put("MC", "中国澳门");
areaMap.put("TW", "中国台湾");
areaMap.put("OTHER", "其他地区");
}
}
特地试了一下,排除异常的情况，每1,000,000此循环
if..else 根据命中几率递增，第一个最快15ms，第二个命中基本上与Map持平23ms，到第三个比Enum稍快31ms
Map 基本上保持在24ms左右
Enum 基本上在36ms左右
还没有来得及出性能测试呢，被仁兄抢先了。
15 楼
zhang_xzhi_xjtu
2011-03-04
Willam2004 写道
一般java源文件中是不推荐直接写中文，可以通过资源文件来进行管理，是不是更好。
同意，但是不是本文的关注点。
14 楼
zhang_xzhi_xjtu
2011-03-04
ak121077313 写道
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
代码格式化一下看看。
13 楼
zhang_xzhi_xjtu
2011-03-04
neo_q 写道
这段代码别的全貌不好说，但是就null判断还是有意义的，
1.可以以短路的形式减少对API的调用；
2.对于使用的API方法，你做出了null safe的假设（尽管你可能是看了源码或者读了它的doc），而事实上，一个API是不应该有假设的，也就是说你作为调用者不应当假设你所调用的接口满足某些条件或者前提，只有这样子接口之间的依赖才会小，达成低耦合的效果；对于假设而言又或者在1.0版本是null safe，2.0不是了，那么你是否要改代码？所以在调用外部API时，最好不要做出假设，这也是OO设计的原则。
1.可以以短路的形式减少对API的调用；
2.对于使用的API方法，你做出了null safe的假设（尽管你可能是看了源码或者读了它的doc），而事实上，一个API是不应该有假设的，也就是说你作为调用者不应当假设你所调用的接口满足某些条件或者前提，只有这样子接口之间的依赖才会小，达成低耦合的效果；对于假设而言又或者在1.0版本是null safe，2.0不是了，那么你是否要改代码？所以在调用外部API时，最好不要做出假设，这也是OO设计的原则。
1 同意，由于场景的实际情况，调用的时候最多的情况不为null，考虑情况不应该这么写。
2 不同意。api已经注明了是null safe。另，一个方法，如果你不相信它的某些条件或者前提，这个方法你就不应该调用。著名的例子就是2分搜索。2.0如果改动的话，因为涉及到接口定义的改动，应该新建一个方法。
12 楼
zhang_xzhi_xjtu
2011-03-04
Crusader 写道
zhang_xzhi_xjtu 写道
每当看到代码中有一个明显的冗余的时候，我就有一个感慨，这家伙时间真多啊，放个屁还要脱裤子。
看例子。
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。文件往下一拉，果不其然。
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
看例子。
if (addressCode != null
&& (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN) || StringUtil
.equals(addressCode, OTHER))) {
// do something.
} else {
// do something.
}
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
if (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN)
|| StringUtil.equals(addressCode, OTHER)) {
// do something.
} else {
// do something.
}
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。文件往下一拉，果不其然。
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
}
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
}
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
}
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
}
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
if (addressMap.containsKey(addressCode)) {
// do something.
} else {
// do something.
}
if (addressMap.containsKey(addressCode)) {
return addressMap.get(addressCode);
} if (addressCode != null
&& (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN) || StringUtil
.equals(addressCode, OTHER))) {
// do something.
} else {
// do something.
}
addressCode如果为null的话，直接短路，至少可以减少一次方法调用啊
有些人处处都很注意性能，习惯问题，也没到脱裤子放屁那么严重
鉴于公司原因代码不能全部开放，考虑性能的话就不会这么写了，因为不为null的情况是最多的。
11 楼
Ben.Sin
2011-03-04
buzhucele 写道
ak121077313 写道
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
如果第一个就命中是if..else效率比较高，但是如果后面的命中，Map明显比if..else效率高
package ben.test.performance.ifelse;
import java.util.HashMap;
import java.util.Map;
public class MapIfEnum {
public static final String HK = "HK";
public static final String MACAO = "MC";
public static final String TW = "TW";
public static final String OTHER = "OTHER";
public static void main(String[] args){
// String code = HK;
// String code = MACAO;
// String code = TW;
String code = OTHER;
MapIfEnum test = new MapIfEnum();
long start = 0L + System.currentTimeMillis();
for (int i = 0; i < 1000000; i ++){
test.useIfElse(code);
// test.useEnum(code);
// test.useMap(code);
}
long end = 0L + System.currentTimeMillis();
System.out.println("Used time = " + (end - start));
}
public String useIfElse(String code){
if (HK.equals(code)){
return "中国香港";
} else if (MACAO.equals(code)){
return "中国澳门";
} else if (TW.equals(code)){
return "中国台湾";
} else {
return "其他地区";
}
}
public String useEnum(String code){
return Area.valueOf(code).getDesc();
}
public String useMap(String code){
return areaMap.get(code);
}
enum Area{
HK("中国香港"),
MC("中国澳门"),
TW("中国台湾"),
OTHER("其他地区");
private String desc;
private Area(String desc){
this.desc = desc;
}
public String getDesc(){
return desc;
}
}
public static Map<String, String> areaMap = new HashMap<String, String>();
static {
areaMap.put("HK", "中国香港");
areaMap.put("MC", "中国澳门");
areaMap.put("TW", "中国台湾");
areaMap.put("OTHER", "其他地区");
}
}
特地试了一下,排除异常的情况，每1,000,000此循环
if..else 根据命中几率递增，第一个最快15ms，第二个命中基本上与Map持平23ms，到第三个比Enum稍快31ms
Map 基本上保持在24ms左右
Enum 基本上在36ms左右
10 楼
Willam2004
2011-03-04
一般java源文件中是不推荐直接写中文，可以通过资源文件来进行管理，是不是更好。
9 楼
buzhucele
2011-03-04
ak121077313 写道
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
这种写法要是效率上应该比用Map高，不过返回一个字符变量在代码的可读性和易易维护性要好一些。
8 楼
ak121077313
2011-03-04
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
return "中国香港";
} else{
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
} else{
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
} else{
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
} }}
}
.........
7 楼
neo_q
2011-03-04
这段代码别的全貌不好说，但是就null判断还是有意义的，1.可以以短路的形式减少对API的调用；2.对于使用的API方法，你做出了null safe的假设（尽管你可能是看了源码或者读了它的doc），而事实上，一个API是不应该有假设的，也就是说你作为调用者不应当假设你所调用的接口满足某些条件或者前提，只有这样子接口之间的依赖才会小，达成低耦合的效果；对于假设而言又或者在1.0版本是null safe，2.0不是了，那么你是否要改代码？所以在调用外部API时，最好不要做出假设，这也是OO设计的原则。
6 楼
Crusader
2011-03-04
zhang_xzhi_xjtu 写道
每当看到代码中有一个明显的冗余的时候，我就有一个感慨，这家伙时间真多啊，放个屁还要脱裤子。
看例子。
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。文件往下一拉，果不其然。
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
看例子。
if (addressCode != null
&& (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN) || StringUtil
.equals(addressCode, OTHER))) {
// do something.
} else {
// do something.
}
其中StringUtil是一个null safe的方法，HK，MACAO，TAIWAN都是常量定义，后面明明有判断相等的逻辑，偏偏要在前面做一个null检查，真是多此一举。
if (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN)
|| StringUtil.equals(addressCode, OTHER)) {
// do something.
} else {
// do something.
}
直接去掉不是挺好的吗?
同时，从这里使用常量的方式可以推测，有可能其他地方也有基于比较的用法。文件往下一拉，果不其然。
if (StringUtil.equals(addressCode, HK)) {
return "中国香港";
}
if (StringUtil.equals(addressCode, MACAO)) {
return "中国澳门";
}
if (StringUtil.equals(addressCode, TAIWAN)) {
return "中国台湾";
}
if (StringUtil.equals(addressCode, OTHER)) {
return "其它国家/地区";
}
两处放在一起考虑，使用map来存储addressCode和地址描述字符串就是一个水到渠成的事情了。
if (addressMap.containsKey(addressCode)) {
// do something.
} else {
// do something.
}
if (addressMap.containsKey(addressCode)) {
return addressMap.get(addressCode);
} if (addressCode != null
&& (StringUtil.equals(addressCode, HK)
|| StringUtil.equals(addressCode, MACAO)
|| StringUtil.equals(addressCode, TAIWAN) || StringUtil
.equals(addressCode, OTHER))) {
// do something.
} else {
// do something.
}
addressCode如果为null的话，直接短路，至少可以减少一次方法调用啊
有些人处处都很注意性能，习惯问题，也没到脱裤子放屁那么严重
发表评论
-
实践中的重构32_使用标准的IO操作写法。
2012-07-14 18:42 1360看到这样一段代码，功能为读取一个指定文件的内容然后返回。 ... -
实践中的重构31_结果类两种实现的比较
2011-09-13 19:58 1068在查询接口结果类设计 ... -
实践中的重构30_不做油漆匠
2011-08-15 23:42 1234油漆匠的故事是编程文化中的一个著名故事。本地化如下。 小强毕业 ... -
实践中的重构29_不自动的自动化测试
2011-07-31 18:00 1036测试的精髓之一就是自 ... -
实践中的重构28_小心怀疑类库
2011-07-24 10:25 1038一般而言，类库的使用频率较高，场景较多，隐藏的bug就较少。 ... -
实践中的重构27_不要忘了内存空间
2011-06-06 18:31 1164方法在设计中，一般关注的是方法的功能契约，即方法需要什么样的参 ... -
实践中的重构26_奇怪的接口注释
2011-06-06 16:10 1330最近又看到奇怪的注释。 /** * 用户查询服务。 ... -
实践中的重构25_UT也需要持续重构
2011-05-01 11:20 957UT是个好东西，在对代 ... -
实践中的重构24_持续的方法重构
2011-05-01 02:20 1065很少有人可以一遍就写出好的代码。写代码和写文章差不多，大部分人 ... -
实践中的重构23_详尽的注释未必是好注释
2011-03-20 17:37 1501注释一直是软件开发中的一个老大难问题。 代码中一个注释都没有是 ... -
实践中的重构22_不要垃圾
2011-03-20 13:31 1038Java引入了GC当然很好，减轻了程序员手工管理内存的负担，但 ... -
实践中的重构21_给她一个好名字
2011-03-20 13:03 897名字的重要性实在是再怎么强调都不为过的。 为什么名字这么重要呢 ... -
实践中的重构20_一段可笑的异常处理逻辑
2011-03-06 20:32 1665Code review也是一个充满 ... -
实践中的重构18_不对称的美
2011-02-26 22:30 969一般而言，自然界是以 ... -
实践中的重构17_表驱动法
2011-02-22 00:10 838代码以及初始的单元测试见 http://zhang-xzhi- ... -
实践中的重构16_多即是少
2011-01-16 23:44 1501在编写UT的过程中，随处可见重复，硬编码等等使得代码僵化的代码 ... -
实践中的重构15_null的意义和集合类作为方法结果类型
2011-01-12 22:16 629在编程中，估计null应该是一个很常写的词汇了。 实践中，经常 ... -
实践中的重构14_用方法设计保证正确性
2011-01-04 21:40 989一般来说，方法的调用方遵循方法的契约调用某方法来完成某功能。每 ... -
实践中的重构13_利用递归提高代码的可维护性
2010-12-30 01:38 722有这么一段代码，是用来解析国内的地址信息的。 AddressI ... -
实践中的重构12_不要乱用异常
2010-12-30 00:36 1467code review的时候，发现了如下代码。 /** ...
相关推荐
用于信号的EMD、EEMD、VMD分解_vmd重构_故障诊断emd_故障诊断_故障重构_VMD信号重构_源码.rar.rar
提取MFCC参数，再由MFCC重构幅值谱，利用幅值谱重构语音。
reconfiguration_配电网_配电网络重构_reconfiguration_配电网重构_配电网重构_源码.zip
重构__改善既有代码的设计_高清 绝对清晰
对经验模态分解后的各分量IMF进行重构代码，函数可直接调用。
mutual_information_相空间重构matlab_互信息熵_源码.zip
牛顿拉普逊法就算配电网重构的潮流程序，结构清晰易懂。
PMSM_无传感器FOC_的单分流三相电流重构算法_01299a_cn
mutual_information_相空间重构matlab_互信息熵.zip
压缩传感重构算法中的子空间追踪算法，用于信号的重构
资源名：用于信号的EMD、EEMD、VMD分解_vmd重构_故障诊断emd_故障诊断_故障重构_VMD信号重构 资源类型：matlab项目全套源码 源码介绍：用于信号的分解、降噪和重构，实现故障诊断 源码说明： 全部项目源码都是经过...
可重构密码_博士论文_COBRA1
初中语文语文论文体验中转换拓展后重构__例谈鲸等常识性课文的教学
配电网重构是一个多目标、多时段、多组合、多约束的非线性优化问题。该问题的复杂性，决定了难以用单纯的数学方法得到满意的解。尝试用改进的遗传算法进行配电网络重构，建立评价函数，寻求该评价函数最优解
医学图像三维重构平台,实现了三维重构用VC++实现
31天重构速成_中文版，通过实例来讲解如何运用模式。
reconfiguration_配电网_配电网络重构_reconfiguration_配电网重构_配电网重构.zip
用户重构0113_20160129094530.rp，用户系统重构产品设计，原型和设计
重构——改善既有代码设计，经典文档，架构师必须教程