zhang_xzhi_xjtu
- 浏览: 538836 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
飞天奔月：
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 1449看到这样一段代码，功能为读取一个指定文件的内容然后返回。 ... -
实践中的重构31_结果类两种实现的比较
2011-09-13 19:58 1100在查询接口结果类设计 ... -
实践中的重构30_不做油漆匠
2011-08-15 23:42 1303油漆匠的故事是编程文化中的一个著名故事。本地化如下。 小强毕业 ... -
实践中的重构29_不自动的自动化测试
2011-07-31 18:00 1072测试的精髓之一就是自 ... -
实践中的重构28_小心怀疑类库
2011-07-24 10:25 1073一般而言，类库的使用频率较高，场景较多，隐藏的bug就较少。 ... -
实践中的重构27_不要忘了内存空间
2011-06-06 18:31 1198方法在设计中，一般关注的是方法的功能契约，即方法需要什么样的参 ... -
实践中的重构26_奇怪的接口注释
2011-06-06 16:10 1366最近又看到奇怪的注释。 /** * 用户查询服务。 ... -
实践中的重构25_UT也需要持续重构
2011-05-01 11:20 1080UT是个好东西，在对代 ... -
实践中的重构24_持续的方法重构
2011-05-01 02:20 1100很少有人可以一遍就写出好的代码。写代码和写文章差不多，大部分人 ... -
实践中的重构23_详尽的注释未必是好注释
2011-03-20 17:37 1565注释一直是软件开发中的一个老大难问题。 代码中一个注释都没有是 ... -
实践中的重构22_不要垃圾
2011-03-20 13:31 1074Java引入了GC当然很好，减轻了程序员手工管理内存的负担，但 ... -
实践中的重构21_给她一个好名字
2011-03-20 13:03 928名字的重要性实在是再怎么强调都不为过的。 为什么名字这么重要呢 ... -
实践中的重构20_一段可笑的异常处理逻辑
2011-03-06 20:32 1723Code review也是一个充满 ... -
实践中的重构18_不对称的美
2011-02-26 22:30 1002一般而言，自然界是以 ... -
实践中的重构17_表驱动法
2011-02-22 00:10 875代码以及初始的单元测试见 http://zhang-xzhi- ... -
实践中的重构16_多即是少
2011-01-16 23:44 1528在编写UT的过程中，随处可见重复，硬编码等等使得代码僵化的代码 ... -
实践中的重构15_null的意义和集合类作为方法结果类型
2011-01-12 22:16 657在编程中，估计null应该是一个很常写的词汇了。 实践中，经常 ... -
实践中的重构14_用方法设计保证正确性
2011-01-04 21:40 1034一般来说，方法的调用方遵循方法的契约调用某方法来完成某功能。每 ... -
实践中的重构13_利用递归提高代码的可维护性
2010-12-30 01:38 748有这么一段代码，是用来解析国内的地址信息的。 AddressI ... -
实践中的重构12_不要乱用异常
2010-12-30 00:36 1550code review的时候，发现了如下代码。 /** ...
相关推荐
描述中的“幅值谱重构语音”指的是从MFCC中恢复出幅度谱，然后使用IFFT将其转换回时间序列。 **谱重构**是指根据频率域信息（如幅度谱或功率谱）重建原始信号的过程。在语音处理中，谱重构对于语音识别、语音合成...
标题中的“用于信号的EMD、EEMD、VMD分解_vmd重构_故障诊断emd_故障诊断_故障重构_VMD信号重构_源码.rar.rar”揭示了该压缩包文件包含的是与信号处理相关的源代码，特别是涉及了三种重要的信号分解方法：Empirical ...
在描述中提到的"对经验模态分解后的各分量IMF进行重构代码，函数可直接调用"，意味着这个压缩包中包含了一个名为"EMDchonggou.m"的MATLAB脚本文件，该文件提供了实现IMF重构功能的代码。用户可以直接运行这个函数，...
重构__改善既有代码的设计_高清 绝对清晰
牛顿拉普逊法就算配电网重构的潮流程序，结构清晰易懂。
配电网重构是电力系统领域中的一个重要研究课题，它涉及到电力系统的稳定运行与经济效率。配电网重构的目标是在满足一系列约束条件下，通过改变开关状态，优化网络结构，以达到提高供电可靠性、降低运营成本、改善...
《重构：改善既有代码设计》是一本由Martin Fowler所著的经典IT著作，它详细阐述了在软件开发过程中如何通过重构来提升代码质量、可读性和维护性。重构是一种系统性的方法，旨在不改变软件外在行为的前提下，改进其...
在本文中，我们将深入探讨基于Matlab的压缩感知（Compressive Sensing，简称CS）重构算法的实现。压缩感知是一种理论先进的信号处理方法，它允许我们以远低于奈奎斯特定理所要求的采样率捕获信号，并能恢复原始信号...
在IT行业中，尤其是在医疗影像处理领域，三维重构技术扮演着至关重要的角色。"NewPrjName.rar" 是一个与三维医学图像重构相关的项目文件压缩包，它涉及到的是使用C++编程语言来实现这一复杂的计算过程。这个项目的...
压缩传感重构算法中的子空间追踪算法，用于信号的重构
资源名：用于信号的EMD、EEMD、VMD分解_vmd重构_故障诊断emd_故障诊断_故障重构_VMD信号重构 资源类型：matlab项目全套源码 源码介绍：用于信号的分解、降噪和重构，实现故障诊断 源码说明： 全部项目源码都是经过...
这个压缩包中的"第13章 MATLAB图像重构实战"可能包含了一系列的MATLAB脚本和函数，用于演示如何使用MATLAB实现fanbeam变换。这些脚本可能包括数据读取、预处理、fanbeam投影、反投影以及图像重构等步骤。在学习和...
在IT领域，尤其是在信号处理和数据采集系统中，压缩感知（Compressed Sensing，简称CS）是一个非常重要的理论。这个理论突破了传统采样定理的限制，允许以远低于奈奎斯特定理所规定的速率对信号进行采样，然后通过...
在电力系统领域，配电网重构是一项关键的技术，其目的是通过改变配电网络的...总之，配电网重构源码的获取为研究和实践提供了宝贵的工具，通过深入学习和应用，可以提升电力系统的运行效率，为智能电网的发展做出贡献。
北理新源，TBOX项目RTT代码重构项目_BTFS_TBOX_RTT
经验模态分解（Empirical Mode Decomposition，简称EMD）是一种强大的数据分析技术，尤其...通过对这些资源的深入理解和实践，我们可以更好地掌握EMD技术，并将其应用到实际问题中，实现非平稳信号的有效分析和重构。
在本项目中，作者计算了重构图像与原始图像的误差，这是评估重构质量的重要指标。通常使用的误差度量有均方误差（Mean Square Error, MSE）、峰值信噪比（Peak Signal-to-Noise Ratio, PSNR）等。MSE是衡量两个图像...
用户重构0113_20160129094530.rp，用户系统重构产品设计，原型和设计
在OMP中，信号被分解为一系列原子（如基函数或字典元素），每次迭代选择与残差最相关的原子，然后更新信号的近似值，直到达到预设的迭代次数或重构误差阈值。 具体来说，OMP的工作流程如下： 1. 初始化：设定一个空...