- 浏览: 542360 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
飞天奔月:
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 1459看到这样一段代码,功能为读取一个指定文件的内容然后返回。 ... -
实践中的重构31_结果类两种实现的比较
2011-09-13 19:58 1104在查询接口结果类设计 ... -
实践中的重构30_不做油漆匠
2011-08-15 23:42 1309油漆匠的故事是编程文化中的一个著名故事。本地化如下。 小强毕业 ... -
实践中的重构29_不自动的自动化测试
2011-07-31 18:00 1077测试的精髓之一就是自 ... -
实践中的重构28_小心怀疑类库
2011-07-24 10:25 1082一般而言,类库的使用频率较高,场景较多,隐藏的bug就较少。 ... -
实践中的重构27_不要忘了内存空间
2011-06-06 18:31 1204方法在设计中,一般关注的是方法的功能契约,即方法需要什么样的参 ... -
实践中的重构26_奇怪的接口注释
2011-06-06 16:10 1370最近又看到奇怪的注释。 /** * 用户查询服务。 ... -
实践中的重构25_UT也需要持续重构
2011-05-01 11:20 1125UT是个好东西,在对代 ... -
实践中的重构24_持续的方法重构
2011-05-01 02:20 1105很少有人可以一遍就写出好的代码。写代码和写文章差不多,大部分人 ... -
实践中的重构23_详尽的注释未必是好注释
2011-03-20 17:37 1578注释一直是软件开发中的一个老大难问题。 代码中一个注释都没有是 ... -
实践中的重构22_不要垃圾
2011-03-20 13:31 1078Java引入了GC当然很好,减轻了程序员手工管理内存的负担,但 ... -
实践中的重构21_给她一个好名字
2011-03-20 13:03 932名字的重要性实在是再怎么强调都不为过的。 为什么名字这么重要呢 ... -
实践中的重构20_一段可笑的异常处理逻辑
2011-03-06 20:32 1735Code review也是一个充满 ... -
实践中的重构18_不对称的美
2011-02-26 22:30 1008一般而言,自然界是以 ... -
实践中的重构17_表驱动法
2011-02-22 00:10 889代码以及初始的单元测试见 http://zhang-xzhi- ... -
实践中的重构16_多即是少
2011-01-16 23:44 1534在编写UT的过程中,随处可见重复,硬编码等等使得代码僵化的代码 ... -
实践中的重构15_null的意义和集合类作为方法结果类型
2011-01-12 22:16 662在编程中,估计null应该是一个很常写的词汇了。 实践中,经常 ... -
实践中的重构14_用方法设计保证正确性
2011-01-04 21:40 1069一般来说,方法的调用方遵循方法的契约调用某方法来完成某功能。每 ... -
实践中的重构13_利用递归提高代码的可维护性
2010-12-30 01:38 753有这么一段代码,是用来解析国内的地址信息的。 AddressI ... -
实践中的重构12_不要乱用异常
2010-12-30 00:36 1572code review的时候,发现了如下代码。 /** ...
相关推荐
矢量边界,行政区域边界,精确到乡镇街道,可直接导入arcgis使用
毕业设计
毕业设计
经验贝叶斯EB的简单例子
智慧园区,作为现代城市发展的新形态,旨在通过高度集成的信息化系统,实现园区的智能化管理与服务。该方案提出,利用智能手环、定制APP、园区管理系统及物联网技术,将园区的各类设施与设备紧密相连,形成一个高效、便捷、安全的智能网络。从智慧社区到智慧酒店,从智慧景区到智慧康养,再到智慧生态,五大应用板块覆盖了园区的每一个角落,为居民、游客及工作人员提供了全方位、个性化的服务体验。例如,智能手环不仅能实现定位、支付、求助等功能,还能监测用户健康状况,让科技真正服务于生活。而智慧景区的建设,更是通过大数据分析、智能票务、电子围栏等先进技术,提升了游客的游玩体验,确保了景区的安全有序。 尤为值得一提的是,方案中的智慧康养服务,展现了科技对人文关怀的深刻体现。通过智慧手环与传感器,自动感知老人身体状态,及时通知家属或医疗机构,有效解决了“空巢老人”的照护难题。同时,智慧生态管理系统的应用,实现了对大气、水、植被等环境要素的实时监测与智能调控,为园区的绿色发展提供了有力保障。此外,方案还提出了建立全域旅游营销平台,整合区域旅游资源,推动旅游业与其他产业的深度融合,为区域经济的转型升级注入了新的活力。 总而言之,这份智慧园区建设方案以其前瞻性的理念、创新性的技术和人性化的服务设计,为我们展示了一个充满智慧与活力的未来园区图景。它不仅提升了园区的运营效率和服务质量,更让科技真正融入了人们的生活,带来了前所未有的便捷与舒适。对于正在规划或实施智慧园区建设的决策者而言,这份方案无疑提供了一份宝贵的参考与启示,激发了他们对于未来智慧生活的无限遐想与憧憬。
数学建模相关主题资源2
内容概要:本文围绕SQL在求职和实际工作中的应用展开,详细解析了SQL的重要性及其在不同行业中不可替代的地位。文章首先强调了SQL作为“一切数据工作的起点”,是数据分析、数据挖掘等领域必不可少的技能,并介绍了SQL与其他编程语言在就业市场的对比情况。随后重点探讨了SQL在面试过程中可能出现的挑战与应对策略,具体涉及到询问澄清问题、正确选择JOIN语句类型、恰当使用GROUP BY及相关过滤条件的区别、理解和运用窗口函数等方面,并给出了详细的实例和技巧提示。另外提醒面试者要注意重复值和空值等问题,倡导与面试官及时沟通。文中引用IEEE Spectrum编程语言排行榜证明了SQL不仅广泛应用于各行各业,在就业市场上也最受欢迎。 适用人群:从事或打算转入数据科学领域(包括但不限于数据分析师、数据科学家、数据工程师等职业方向),并对掌握和深入理解SQL有一定需求的专业人士,尤其是正准备涉及SQL相关技术面试的求职者。 使用场景及目标:帮助用户明确在面对复杂的SQL查询题目时能够更加灵活应对,提高解题效率的同时确保准确性;同时让用户意识到SQL不仅仅是简单的数据库查询工具,而是贯穿整个数据处理流程的基础能力之一,进而激发他们进一步探索的热情。 其他说明:SQL在性能方面优于Excel尤其适用于大规模数据操作;各知名企业仍将其视为标准数据操作手段。此外还提供了对初学者友好的建议,针对留学生普遍面临的难题如零散的学习资料、昂贵且效果不佳的付费教程以及难以跟上的纯英教学视频给出了改进的方向。
COMSOL仿真揭示石墨烯临界耦合光吸收特性:费米能级调控下的光学性能探究,COMSOL仿真揭示石墨烯临界耦合光吸收特性:费米能级调控下的光学性能探究,COMSOL 准 BIC控制石墨烯临界耦合光吸收。 COMSOL 光学仿真,石墨烯,光吸收,费米能级可调下图是仿真文件截图,所见即所得。 ,COMSOL; 准BIC; 石墨烯; 临界耦合光吸收; 光学仿真; 费米能级可调。,COMSOL仿真:石墨烯光吸收的BIC控制与费米能级调节
Labview与Proteus串口仿真下的温度采集与报警系统:Keil单片机程序及全套视频源码解析,Labview与Proteus串口仿真温度采集及上位机报警系统实战教程:设定阈值的Keil程序源码分享,labview 和proteus 联合串口仿真 温度采集 上位机报警 设定阈值单片机keil程序 整套视频仿真源码 ,关键词:LabVIEW;Proteus;串口仿真;温度采集;上位机报警;阈值设定;Keil程序;视频仿真源码。,LabVIEW与Proteus联合串口仿真:温度采集与报警系统,Keil程序与阈值设定全套视频源码
整车性能目标书:涵盖燃油车、混动车及纯电动车型的十六个性能模块目标定义模板与集成开发指南,整车性能目标书:涵盖燃油车、混动车及纯电动车型的十六个性能模块目标定义模板与集成开发指南,整车性能目标书,汽车性能目标书,十六个性能模块目标定义模板,包含燃油车、混动车型及纯电动车型。 对于整车性能的集成开发具有较高的参考价值 ,整车性能目标书;汽车性能目标书;性能模块目标定义模板;燃油车;混动车型;纯电动车型;集成开发;参考价值,《汽车性能模块化目标书:燃油车、混动车及纯电动车的集成开发参考》
熵值法stata代码(含stata代码+样本数据) 面板熵值法是一种在多指标综合评价中常用的数学方法,主要用于对不同的评价对象进行量化分析,以确定各个指标在综合评价中的权重。该方法结合了熵值理论和面板数据分析,能够有效地处理包含多个指标的复杂数据。
“电子电路”仿真资源(Multisim、Proteus、PCB等)
在 GEE(Google Earth Engine)中,XEE 包是一个用于处理和分析地理空间数据的工具。以下是对 GEE 中 XEE 包的具体介绍: 主要特性 地理数据处理:提供强大的函数和工具,用于处理遥感影像和其他地理空间数据。 高效计算:利用云计算能力,支持大规模数据集的快速处理。 可视化:内置可视化工具,方便用户查看和分析数据。 集成性:可以与其他 GEE API 和工具无缝集成,支持多种数据源。 适用场景 环境监测:用于监测森林砍伐、城市扩展、水体变化等环境问题。 农业分析:分析作物生长、土地利用变化等农业相关数据。 气候研究:研究气候变化对生态系统和人类活动的影响。
内容概要:本文介绍了C++编程中常见指针错误及其解决方案,并涵盖了模板元编程的基础知识和发展趋势,强调了高效流操作的最新进展——std::spanstream。文章通过一系列典型错误解释了指针的安全使用原则,强调指针初始化、内存管理和引用安全的重要性。随后介绍了模板元编程的核心特性,展示了编译期计算、类型萃取等高级编程技巧的应用场景。最后,阐述了C++23中引入的新特性std::spanstream的优势,对比传统流处理方法展现了更高的效率和灵活性。此外,还给出了针对求职者的C++技术栈学习建议,涵盖了语言基础、数据结构与算法及计算机科学基础领域内的多项学习资源与实战练习。 适合人群:正在学习C++编程的学生、从事C++开发的技术人员以及其他想要深入了解C++语言高级特性的开发者。 使用场景及目标:帮助读者掌握C++中的指针规则,预防潜在陷阱;介绍模板元编程的相关技术和优化方法;使读者理解新引入的标准库组件,提高程序性能;引导C++学习者按照有效的路径规划自己的技术栈发展路线。 阅读建议:对于指针部分的内容,应当结合实际代码样例反复实践,以便加深理解和记忆;在研究模板元编程时,要从简单的例子出发逐步建立复杂模型的理解能力,培养解决抽象问题的能力;而对于C++23带来的变化,则可以通过阅读官方文档并尝试最新标准特性来加深印象;针对求职准备,应结合个人兴趣和技术发展方向制定合理的学习计划,并注重积累高质量的实际项目经验。
JNA、JNI, Java两种不同调用DLL、SO动态库方式读写FM1208 CPU卡示例源码,包括初始化CPU卡、创建文件、修改文件密钥、读写文件数据等操作。支持Windows系统、支持龙芯Mips、LoongArch、海思麒麟鲲鹏飞腾Arm、海光兆芯x86_Amd64等架构平台的国产统信、麒麟等Linux系统编译运行,内有jna-4.5.0.jar包,vx13822155058 qq954486673
内容概要:本文全面介绍了Linux系统的各个方面,涵盖入门知识、基础操作、进阶技巧以及高级管理技术。首先概述了Linux的特点及其广泛的应用领域,并讲解了Linux环境的搭建方法(如使用虚拟机安装CentOS),随后深入剖析了一系列常用命令和快捷键,涉及文件系统管理、用户和权限设置、进程和磁盘管理等内容。此外,还讨论了服务管理的相关指令(如nohup、systemctl)以及日志记录和轮替的最佳实践。这不仅为初学者提供了一个完整的知识框架,也为中级和高级用户提供深入理解和优化系统的方法。 适合人群:适用于有意深入了解Linux系统的学生和专业技术人员,特别是需要掌握服务器运维技能的人群。 使用场景及目标:本文适合初次接触Linux的操作员了解基本概念;也适合作为培训教材,指导学生逐步掌握各项技能。对于有一定经验的技术人员而言,则可以帮助他们巩固基础知识,并探索更多的系统维护和优化可能性。 阅读建议:建议按照文章结构循序渐进地学习相关内容,尤其是结合实际练习操作来加深记忆和理解。遇到复杂的问题时可以通过查阅官方文档或在线资源获得更多帮助。
内容概要:本文档详细介绍了企业在规范运维部门绩效管理过程中所建立的一套绩效考核制度。首先阐述了绩效考核制度设立的目的为确保绩效目标得以衡量与追踪,并确保员工与公司共同成长与发展。其次规定范围覆盖公司所有在职员工,并详细列明了从总经理到一线员工在内的不同角色的职责范围。再则描述了完整的绩效工作流程,即从年初开始制定绩效管理活动计划,经过与每个员工制定具体的绩效目标,在绩效考核周期之内对员工的工作进展和问题解决状况进行持续的监督跟进,并且在每周期结束前完成员工绩效的评估和反馈工作,同时利用绩效评估结果对员工作出保留或异动的相关决定,最后进行绩效管理活动总结以为来年提供参考。此外还强调了整个过程中必要的相关文档保存,如员工绩效评估表。 适合人群:企业管理层,HR专业人士及对现代企业内部运营管理感兴趣的读者。 使用场景及目标:①管理层需要理解如何规范和有效实施企业内部绩效管理,以提高公司运营效率和员工满意度;②HR人士可以通过参考此文档来优化自己公司的绩效管理体系;③对企业和组织管理有兴趣的研究员亦可借鉴。 阅读建议:读者应重点关注各个层级管理者和员工在整个流程中的角色和责任,以期更好地理解
基于MATLAB Simulink的LCL三相并网逆变器仿真模型:采用交流电流内环PR控制与SVPWM-PWM波控制研究,基于MATLAB Simulink的LCL三相并网逆变器仿真模型研究:采用比例谐振控制与交流SVPWM控制策略及参考文献解析,LCL_Three_Phase_inverter:基于MATLAB Simulink的LCL三相并网逆变器仿真模型,交流电流内环才用PR(比例谐振)控制,PWM波采用SVPWM控制,附带对应的参考文献。 仿真条件:MATLAB Simulink R2015b,前如需转成低版本格式请提前告知,谢谢。 ,LCL三相并网逆变器; LCL_Three_Phase_inverter; MATLAB Simulink; PR控制; SVPWM控制; 仿真模型; 参考文献; 仿真条件; R2015b版本,基于PR控制与SVPWM的LCL三相并网逆变器Simulink仿真模型研究
内点法求解标准节点系统最优潮流计算的稳定程序,注释清晰,通用性强,内点法用于标准节点系统的最优潮流计算:稳定、通用且注释清晰的matlab程序,内点法最优潮流程序matlab 采用内点法对14标准节点系统进行最优潮流计算,程序运行稳定,注释清楚,通用性强 ,内点法; 最优潮流程序; MATLAB; 14标准节点系统; 稳定运行; 清晰注释; 通用性强。,Matlab内点法最优潮流程序:稳定高效,通用性强,适用于14节点系统
17suiea3.apk?v=1741006890849