打字猴:1.70043951e+09
1700439510
1700439511 public class Client{
1700439512
1700439513 public static void main(String[]args){
1700439514
1700439515 System.out.println(“2=”+toChineseNumberCase(2));
1700439516
1700439517 }
1700439518
1700439519 //把阿拉伯数字翻译成中文大写数字
1700439520
1700439521 public static String toChineseNumberCase(int n){
1700439522
1700439523 String chineseNumber=””;
1700439524
1700439525 switch(n){
1700439526
1700439527 case 0:chineseNumber=“零”;
1700439528
1700439529 case 1:chineseNumber=“壹”;
1700439530
1700439531 case 2:chineseNumber=“贰”;
1700439532
1700439533 case 3:chineseNumber=“叁”;
1700439534
1700439535 case 4:chineseNumber=“肆”;
1700439536
1700439537 case 5:chineseNumber=“伍”;
1700439538
1700439539 case 6:chineseNumber=“陆”;
1700439540
1700439541 case 7:chineseNumber=“柒”;
1700439542
1700439543 case 8:chineseNumber=“捌”;
1700439544
1700439545 case 9:chineseNumber=“玖”;
1700439546
1700439547 }
1700439548
1700439549 return chineseNumber;
1700439550
1700439551 }
1700439552
1700439553 }
1700439554
1700439555 这是一个简单的转换类,并没有完整实现,只是一个金融项目片段。如此简单的代码应该不会有错吧,我们运行看看,结果是:2=玖。
1700439556
1700439557 恩?错了?回头再来看程序,马上醒悟了:每个case语句后面少加了break关键字。程序从“case 2”后面的语句开始执行,直到找到最近的break语句结束,但可惜的是我们的程序中没有break语句,于是在程序执行的过程中,chineseNumber的赋值语句会多次执行,会从等于“贰”、等于“叁”、等于“肆”,一直变换到等于“玖”,switch语句执行结束了,于是结果也就如此了。
1700439558
1700439559 此类问题发生得非常频繁,但也很容易发现,只要做一下单元测试(Unit Test),问题立刻就会被发现并解决掉,但如果是在一堆的case语句中,其中某一条漏掉了break关键字,特别是在单元测试覆盖率不够高的时候(为什么不够高?在大点的项目中蹲过坑、打过仗的兄弟们可能都知道,项目质量是与项目工期息息相关的,而项目工期往往不是由项目人员决定的,所以如果一个项目的单元测试覆盖率能够达到60%,你就可以笑了),也就是说分支条件可能覆盖不到的时候,那就会在生产中出现大事故了。
[ 上一页 ]  [ :1.70043951e+09 ]  [ 下一页 ]