程序的风格要素.ppt

为什么要讲求程序的风格 程序风格的要素包括哪些 如何实践 程序风格的最主要的作用就是让代码更容易懂，无论对程序员本人还是其他的人。好的程序风格对于好的程序设计具有关键作用，而这一点也往往是最容易被人所忽略的。 好的风格让代码更易读 好的风格让思维更缜密 好的风格让程序更高效 好的风格让改变更容易 好的风格让…… if (!this.mOperate.equals(DELETE||PROPOSAL)) { if (this.mOperate.equals(INSERT||PROPOSAL)) { if (!CheckTBField(INSERT)) { return false; } } else { if (!CheckTBField(UPDATE)) { return false; } } } 首先我们抛开这个问题来讨论一下另外一个问题：程序风格从何而来？答案很清楚：同行们从日常堆代码的过程中总结得来的。那么我们的标题中的问题也就很容易回答了：程序的风格要素包括我们编码的每个环节。 单元命名 词法组织 模块编写 常数的定义 注释的编写 正确的 一致的 清晰的 简洁的 高效的 在这个拼命要把代码送出门、去赶上Deadline的时代，程序员很容易把风格丢到一旁，但是这样做的带来的后果往往很严重：草率的代码难以维护、执行效率低下、容易崩溃。而让好的风格在编码过程中得到实践的方法也很容易：那就是了解并牢记它们，让它变成你的习惯。 风格： 准确的、一致的、简练的、易记的、可拼读的（如果可能） 全局变量使用具有说明性的名字，局部变量使用短名字。 函数采用动作性的名字或者判断性的名字 收益： 好的命名可以减少阅读者对注释的依赖 帮助程序员思考，提高开发效率 减少错误（Jsp中定义confirm方法） package 命名 Package 的名字应该都是由一个小写单词组成。 Class 的命名 Class 的名字必须由大写字母开头。后面的单词用大写字母开头。 Class 变量的命名 变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。 Static Final 变量的命名 Static Final 变量的名字应该都大写，并且指出完整含义。 参数的命名 参数的名字必须和变量的命名规范一致。 数组的命名 数组应该总是用下面的方式来命名： byte[] buffer; 而不是： byte buffer[]; 方法的参数 使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字： SetCounter(int size){ 　　this.size = size; } 不好的例子 If(month==FEB){ if(year%4==0) if(day29) legal==false; else if(day28) legal==false; } 正确的写法 if((year%4)==0) { if(day29) legal=false; } else { if(day28) legal=false; } 程序封装： 为什么一段看起来很简单的功能也要被封装为一个函数或者方法？为什么有的传入参数看起来不用也可以？ 资源管理： 哪些信息是独自使用的？ 哪些信息是共享的？设置为static 错误处理： 哪些错误可能会发生？Catch到的Exception 哪些错误需要处理？ 其他的风格要素：模块长度、初始化、排序 封装的最大受益人是程序员自己，毕竟我们写的程序大多是要再次阅读的，封装带来的最大收益就是层次化，而层次化对于阅读来说是必须的——封装是化整为零的风格。 封装的第二受益人是客户（从某种程度上说还是我们自己），当需求发生变更时我们往往只需要修改某一个封装的模块即可实现新的功能。 静态变量：共享的信息。如果一个值是永远不会改变的常量，那么把它变成静态常量；如果它是由程序修改的共享的信号变量，那么把它定义为静态变量；如果它是需要由用户来修改的配置性的常量，那么将它写入到数据库中或者配置文件中。 静态方法中只能访问类中的静态变量和静态方法。 Catch到Exception一定要printStackTrace 处理有限的错误（化整为零） 给出正确的错误信息，避免误导，造成更大的错误 以正确的形式给出错误信息（不是所有场景都能弹出一个大大的对话框） 错误处理不应占据程序的过