通常有经验的程序员写出来的代码一开始可读性都是不错的,但随着需求变更,维护人员变化,慢慢架构开始腐化,代码开始变的混乱起来。
还有就是有时仅仅为了完成功能,而完全忽略了代码的可读性(非功能性需求)。
编程时如何保持对代码可读性的持续关注呢,举个小小的例子吧。
有一个简单的需求,写一个方法生成一个字符串key值,传入全类名、调用方法名返回key值,key的长度受外部条件约束不能超过50个字符。
首先看下面这个实现:
private String generateKey(String service, String method) {
String head = "DBO$";
String key = "";
int len = head.length() + service.length() + method.length();
if (len <= 50) {
key = head + service + "." + method;
} else {
service = service.substring(service.lastIndexOf(".") + 1);
len = head.length() + service.length() + method.length();
key = head + service + "." + method;
if (len > 50) {
key = head + method;
if (key.length() > 50) {
key = key.substring(0, 48) + ".*";
}
}
}
return key;
}
方法实现不复杂,很短,看起来也不错。
分析下逻辑:
1、首先 key由固定的头(head)+ service(全类名)+ method(方法)组成,若小于50字符,直接返回
2、若超过50字符限制,则去掉包名,保留类名,再判断一次,若此时小于50字符则返回。
3、若还是超过50字符限制(可能有个变态的家伙起了个很长的类名或方法名),则连类名一起去掉,保留头和方法再判断一次若小于50字符则返回
4、最后如果有个变态长的方法(46+个字符),没办法,只好暴力截断到50字符返回。
这个实现最大限度的在生成key中保留全部的有用信息,对超过限制的情况依次按信息重要程度的不同进行丢弃。
这里只有一个问题,这个业务规则只有4个判断,实现进行了三次if语句嵌套,还好这个方法比较短,可读性还不成问题。
而现实中很多业务规则比这复杂的多,以前看过一些实现的if嵌套多达10层的,方法也长的要命。当然一开始没有嵌套那么多层,只是后来随着时间的演变,业务规则发生了变化,增加了,后来的程序员就按照这种方式继续嵌套下去,慢慢演变至此,到我看到的时候就有10层了。
程序员有一种编程的惯性,特别是进行维护性编程时。一开始接手一个别人做的系统,不可能一下能了解和掌控全局。
当要增加新功能时,在原有代码上添加逻辑,很容易保持原来程序的写法惯性(考虑这样写更安全)。
所以一个10层嵌套if的业务逻辑方法实现,第一个程序员也许只写了3次嵌套,感觉还不错不失简洁。后来写4、5、6层的程序员就是懒惰不愿再改,到了写第8、9、10层的程序员时基本很可能就是不敢再乱动了。代码最后就变成了一大坨*。
考虑下上面个简单的例子,怎么改改比较好呢。我自己写了个实现如下:
private String generateKey(String service, String method) {
String head = "DBO$";
String key = head + service + "." + method;
// head + service(with package) + method
if (key.length() <= 50) {
return key;
}
LOG.info("key = " + key);
// head + service(without package) + method
service = service.substring(service.lastIndexOf(".") + 1);
key = head + service + "." + method;
if (key.length() <= 50) {
return key;
}
// head + method
key = head + method;
if(key.length() <= 50) {
return key;
}
// last, we cut the string to 50 characters limit.
key = key.substring(0, 48) + ".*";
return key;
}
最后,我在写这个小方法时想起好多年前读到过的一个编程建议:函数最好只有一个出口,一个return。
不幸的是这个实现有4个return,而前一个实现确实只有一个return,所以我想说一切编程原则、建议、设计模式都不是绝对的。
它们犹如兵法,可参考,可学习,但兵法的运用还要看天时、地利、人和。
编程也一样,一切根据你需要解决的实际问题去灵活运用,自然能写出最适合的程序。
分享到:
相关推荐
转债再审视之一:基于定价模型的视角
馆校合作之审视与反思:理念、实践及第三方.docx
华创证券-【宏观专题】出口再审视系列一:出口十大高频跟踪框架-230522.pdf
20210329-华安证券-转债再审视之一:基于定价模型的视角.pdf
CVPR2022 - 重新审视池化:你的感受野不是最理想的.doc
周围环境的外观可能会影响游客对食物的期望。 正确设计的服务环境可能会导致访客光顾餐厅。 饭店老板需要了解如何利用服务环境并影响购买行为。 在过去的二十年中,已经对Servicescape模型进行了广泛的讨论,这为...
重新审视淘宝:生态系统重构 变革求变.docx
如果你在开始写代码时就关心风格问题,如果你花时间去审视和改进它,你将会逐渐养成一种好的编程习惯。一旦这种习惯变成自动的东西,你的潜意识就会帮你照料许多细节问题,甚至你在工作压力下写出的代码也会更好。
人工智能艺术的美学审视:基于人文主义美学的视角.pdf
重新审视顾问归因:教学经验与顾问归因的关系 Interpreting Percentile Rank 353 BAILEY, DB, & ROSENTHAL, SL (1987)。 测量和测试开发的基本原理。 在 WH Berdine & SA Meyer (Eds.),特殊教育评估。 ...
也就是说从代码的结构中我们可以直接理解业务的设计,命名得当的话,非程序人员也可以“读”代码。然而在整个DDD的建模过程中,我们更多关注的是核心领域模型的建立,我们认为完成业务的需求就是在领域模型上的一...
要有足够的细心,审视每一行代码,找出错误的根源。也要有足够的耐心,不要因为遇到困难就放弃,而是持之以恒地解决问题。 4. 查阅资料 在学习的过程中,遇到疑问和困难是正常的。不要被卡住,要主动查阅相关文档、教材、...
包含的全部都是c#编码的最佳实践,从语言本身、程序的设计和架构、编码规范和编程习惯等三大方面对c#程序员遇到的经典问题给出了经验性的解决方案,为c#程序员如何编写更高质量的c#代码提供了157条极为宝贵的建议。...
少儿编程培训热的教育学审视.docx
《C嵌入式编程设计模式》以面向对象的视角,重新审视嵌入式系统,全面总结了嵌入式系统中常见的以及关键的设计模式。《C嵌入式编程设计模式》提出了很多新颖的设计模式,为使用c语言编程的嵌入式系统开发者提供了强...
我们现在用一整年的新样本外数据重新审视这个测试,并将其“实时”表现与对冲基金行业进行比较。 虽然传统优化器在去年的表现非常好,但方向协方差技术产生了更加多样化的投资组合,在绝对基础上和风险调整基础上的...
本书的内容、讲授方法,选用例子和跟随的练习,别具特色。作者Bruce Eckel不是按...特别是,他经常通过例子引导读者从C++编译实现的汇编代码的角度反向审视C++的语法和语义,常常使读者有‘心有灵犀一点通’的奇特效果
在本书中,作者用一种幽默、辛辣的眼光审视着发生在程序设计室里的各种各样的小故事,并运用东方的哲学体系进行深层次的思考和理解,即进行“道”式的思考和理解。简单的故事蕴含深奥的道理,是本书的极大特色。您...