良好的编程习惯.docx
《良好的编程习惯.docx》由会员分享，可在线阅读，更多相关《良好的编程习惯.docx（10页珍藏版）》请在冰豆网上搜索。
良好的编程习惯
良好的编程习惯
良好的习惯对于人的成长是非常重要的,良好的编程习惯对于我们编程能力的提高也是非常重要的。
我们编程时要有良好的风格,源代码的逻辑简明清晰,易读易懂是好程序的重要标准。
其实编程的过程中最容易忽略的还是程序的“风格”。
这些东东有时让人挺烦的,刚刚放射出光茫的思想似乎被约束住了,本来是灵感发现,还要在后面罗索上半天。
程序需要风格吗?
让我们的程序写得更加平易近人,更加生动对我们的编程是大有益处的。
对我们的程序学习也能起到事半功倍的作用。
编程过程中遵守的不成文的标准,对于我们和他人的交流和自己的再学习都是有益无害的。
毕竟有时我们写的程序不是只给自己看的,也不是一时兴起,不管以后。
好的编码可使源代码的可读性强且意义清楚,与其他语言约定相一致,并且尽可能直观。
我们自己一眼能看出个大概,在别人眼中也不至于成为千古奇书。
下面以VB为例,对程序风格做一下全面的概述,希望对您的编程水平的提高有所帮助。
一、程序内部文档应具备的规则
1、标识符应含有含义鲜明的文字。
含义鲜明的文字,能正确地提示程序对象所代表的实体。
这对于帮助阅读者理解程序是非常重要的。
如果用缩写的形式,那么缩写规则应该一致,并且应该给每个名字加注解。
在VB中,主要有如下的约定:
（一）对象命名约定
应该使用一致的前缀来命名对象,使人们容易识别对象的类型。
例如我们常用控件CommandButton（命令按钮）可用cmd做为其前缀。
Form以frm,Image以img,Label以lbl,ListBox以lst,PictureBox以pic,Timer以tmr,等等,在我们编程的过程中,我们看到下面的名称cmdExit我们就知道这一定是一个命令按钮了。
如果是第三方提供的控件,我们的说明最好要清晰地标出制造商的名称,
1
以区别于我们的常用控件。
（二）常量和变量命名约定
除了控件以外,常量和变量也是我们编程过程中经常遇到的,我们和他们打交道也是通过名字。
（1）给变量加范围前缀
变量按其作用范围可分做三类,过程级,模块级和全局,所以我们在编程的过程中应将三者加以区别。
我们在使用变量时,为了更好地体现代码重用和可维护原则,其定义范围应尽量缩小,这样将使我们的应用程序更加容易理解和易于控制。
在VB应用程序中,只有当没有其他方便途径在窗体间共享数据时才使用全局变量。
当使用全局变量时,在一个单一模块中声明它们,并按功能分组,给模块取一个有意义的名字。
较好的编码习惯是尽可能地定模块化的代码。
除了全局变量,过程和函数应该仅对传递给它们的的对象操作。
在过程中使用的全局变量应该在过程起始处的声明部分标识出来。
变量的作用范围前缀如下:
全局g（global）,模块级m（model）,本地过程不需要使用。
例如:
gintFlag,表示全局整型变量,mstrPassword,可表示模块级字符型变量。
（2）声明所有变量原则。
声明所有变量将会节省编程时间,键入错误将大大减少,我们可在程序开始写上如下语句:
OptionExplicit
该语句要求在程序中声明所有变量。
（3）变量数据类型声明。
可通过下面的前缀来做为变量的数据类标志。
Booleanbln
Bytebyt
Doubledbl
Integerint
Stringstr
（4）常量。
常量的命名,可遵循与变量命名大体相同的原则。
（5）对变量和过程名作出描述。
变量或过程名的主体应该使用大小写混合的形式,并且应该足够长以描述它的作用。
而且,函数名应以一个动词开头。
如JudgeDialog。
2、适当的注解
注解是程序员和程序读者通信的重要手段,正确的注解非常有助于对程序的理解。
VB中代码注解约定如下:
所有的过程和函数都应该以描述这段过程的功能的一段简明的注释开始,说明该程序是干什么的,至于是如何做的,也就是编程的细节,最好不要包括。
因为可能日后我们要修改程序,这样做会带来不必要的注释维护工作,如果不修改,将提供误导信息,可能成为错误的注释。
因为代码本身和后面程序中的注释将起到相应的说明作用。
过程中的注释块应该包括如下标题:
小节描述内容
目的该过程完成什么
假设列出每个外部变量、控件、打开文件或其他不明显元素
效果列出每个被影响的外部变量、控件或文件及其作用（只有当它不明显时）输入每一个可能不明显的参数。
返回函数返回值的说明
格式化代码
（1）标准的,基于制表位的嵌套应该包括一个嵌注释,来描述该变量的使用。
（2）变量、控件及过程的命名应该足够清楚,使得只有复杂的执行细节才需
要嵌入注释。
（3）.bas模块包含包含工程的VB一般常量声明,在其起始处,应包括程序的综述,列举主要数据对象,过程、算法、对话、数据库及系统需求。
3、程序的视觉组织
程序的视觉组织可用阶梯式,结构化的程序风格对于我们实际编程也很有意义,可极大地改善代码的可读性。
主要有代码注释和一致性缩进。
二、数据说明
数据结构的组织和复杂程序是在设计期间就已经确定了的,然而数据说明的风格却是在写程序时确定的。
为了使数据更容易理解和维护,有一些比较简单的原则应该遵循。
1、数据说明的次序应该标准化。
有次序就容易查阅。
因此能够加速测试、调试和维护的过程。
当多个变量名在一个语句中说明时,应按字母顺序排列这些变量。
2、数据结构复杂时,应加以说明其特点和实现方法。
三、语句构造
语句构造原则:
每个语句应该简单而直接,不能为了提高效率而使程序变得过分复杂。
下述规则的使用有助于语句简单明了。
1、不要为了节省空间把多行语句写在一行;
2、尽量避免复杂的条件测试;
3、尽量减少对“非”条件的测试;
4、避免大量使用循环嵌套和条件嵌套;
5、利用括号使逻辑表达式或算术表达式的运算次序清晰直观。
四、输入输出
1、对所有输入数据都进行检验;
2、检查输入项重要组合的合法性;
3、保持输入格式简单;
4、使用数据结束标志,不要要求用户指定输入数据的数目
5、明确提示交互式输入的请求,详细说明可用的选择或边界数值;
6、当语言对格式有严格要求时,应保持输入格式一致
7、设计良好的输出报表;
8、给所有输出加标志;
五、效率
效率三原则:
1、效率是性能的要求,需求分析时就应确定;
2、效率是靠设计提高的;
3、程序的效率和程序的简单程序是一致的。
（一）运行时间
（1）写程序前先简化算术和逻辑表达式;
（2）他细研究嵌套的循环,以确定是否有语句从内层移到外层;
（3）尽量避免使用多维数组;
（4）尽量避免使用指针和复杂的表;
（5）使用执行时间短的算术运算;
（6）不要混合使用不同的数据类型;
（7）尽量使用整数运算和布尔表达式
（二）存储器效率
（三）输入输出效率
如果用户是为了给计算机提供输入信息或为了理解计算机输入的信息,所需花费的脑力劳动是经济的,那么,人和计算机之间的通信效率就高。
简单清晰是关键。
六、小结
其实风格是非常重要的,程序的外表是我们交流中不可缺少的东西。
象我们常说的红颜命薄而归疚于外表太靓,也常听一些才子佳人的悲剧故事,提醒我们外表美而引出的一见钟情的浪漫不可取。
可让人细想,才子佳人产生悲剧虽多,可也让人找到过心动和美好的感觉,做为一个人,活了一辈子,连那种感觉都未体验到,岂不比悲剧更加令人觉得可悲!
编程亦然。
JAVA
（1）类名首字母应该大写。
字段、方法以及对象（句柄）的首字母应小写。
对于所有标识符,其中包含的所有单词都应紧靠在一起,而且大写中间单词的首字母。
例如:
ThisIsAClassName
thisIsMethodOrFieldName
若在定义中出现了常数初始化字符,则大写staticfinal基本类型标识符中的所有字母。
这样便可标志出它们属于编译期的常数。
Java包（Package）属于一种特殊情况:
它们全都是小写字母,即便中间的单词亦是如此。
对于域名扩展名称,如com,org,net或者edu等,全部都应小写（这也是Java1.1和Java1.2的区别之一）。
（2）为了常规用途而创建一个类时,请采取"经典形式",并包含对下述元素的定义:
equals（）
hashCode（）
toString（）
clone（）（implementCloneable）
implementSerializable
（3）对于自己创建的每一个类,都考虑臵入一个main（）,其中包含了用于测试那个类的代码。
为使用一个项目中的类,我们没必要删除测试代码。
若进行了任何形式的改动,可方便地返回测试。
这些代码也可作为如何使用类的一个示例使用。
（4）应将方法设计成简要的、功能性单元,用它描述和实现一个不连续的类接口部分。
理想情况下,方法应简明扼要。
若长度很大,可考虑通过某种方式将其分割成较短的几个方法。
这样做也便于类内代码的重复使用（有些时候,方法必须非常大,但它们仍应只做同样的一件事情）。
（5）设计一个类时,请设身处地为客户程序员考虑一下（类的使用方法应该是非常
明确的）。
然后,再设身处地为管理代码的人考虑一下（预计有可能进行哪些形式的修改,想想用什么方法可把它们变得更简单）。
（6）使类尽可能短小精悍,而且只解决一个特定的问题。
下面是对类设计的一些建议:
一个复杂的开关语句:
考虑采用"多形"机制
数量众多的方法涉及到类型差别极大的操作:
考虑用几个类来分别实现
许多成员变量在特征上有很大的差别:
考虑使用几个类
（7）让一切东西都尽可能地"私有"--private。
可使库的某一部分"公共化"（一个方法、类或者一个字段等等）,就永远不能把它拿出。
若强行拿出,就可能破坏其他人现有的代码,使他们不得不重新编写和设计。
若只公布自己必须公布的,就可放心大胆地改变其他任何东西。
在多线程环境中,隐私是特别重要的一个因素--只有private字段才能在非同步使用的情况下受到保护。
（8）谨惕"巨大对象综合症"。
对一些习惯于顺序编程思维、且初涉OOP领域的新手,往往喜欢先写一个顺序执行的程序,再把它嵌入一个或两个巨大的对象里。
根据编程原理,对象表达的应该是应用程序的概念,而非应用程序本身。
（9）若不得已进行一些不太雅观的编程,至少应该把那些代码臵于一个类的内部。
（10）任何时候只要发现类与类之间结合得非常紧密,就需要考虑是否采用内部类,从而改善编码及维护工作（参见第14章14.1.2小节的"用内部类改进代码"）。
（11）尽可能细致地加上注释,并用javadoc注释文档语法生成自己的程序文档。
（12）避免使用"魔术数字",这些数字很难与代码很好地配合。
如以后需要修改它,无疑会成为一场噩梦,因为根本不知道"100"到底是指"数组大小"还是"其他全然不同的东西"。
所以,我们应创建一个常数,并为其使用具有说服力的描述性名称,并在整个程序中都采用常数标识符。
这样可使程序更易理解以及更易维护。
（13）涉及构建器和异常的时候,通常希望重新丢弃在构建器中捕获的任何异常--如果它造成了那个对象的创建失败。
这样一来,调用者就不会以为那个对象已正确地创建,从而盲目地继续。
（14）客户程序员用完对象以后,若你的类要求进行任何清除工作,可考虑将清除代码臵于一个良好定义的方法里,采用类似于cleanup（）这样的名字,明确表明自己的用途。
除此以外,可在类内放臵一个boolean（布尔）标记,指出对象是否已被清除。
在类的finalize（）方法里,请确定对象已被清除,并已丢弃了从RuntimeException继承的一个类（如果还没有的话）,从而指出一个编程错误。
在采取象这样的方案之前,请确定finalize（）能够在自己的系统中工作（可能需要调用System.runFinalizersOnExit（true）,从而确保这一行为）。
（15）在一个特定的作用域内,若一个对象必须清除（非由垃圾收集机制处理）,请采用下述方法:
初始化对象;若成功,则立即进入一个含有finally从句的try块,开始清除工作。
（16）若在初始化过程中需要覆盖（取消）finalize（）,请记住调用super.finalize（）（若Object属于我们的直接超类,则无此必要）。
在对finalize（）进行覆盖的过程中,对super.finalize（）的调用应属于最后一个行动,而不应是第一个行动,这样可确保在需要基础类组件的时候它们依然有效。
（17）创建大小固定的对象集合时,请将它们传输至一个数组（若准备从一个方法里返回这个集合,更应如此操作）。
这样一来,我们就可享受到数组在编译期进行类型检查的好处。
此外,为使用它们,数组的接收者也许并不需要将对象"造型"到数组里。
（18）尽量使用interfaces,不要使用abstract类。
若已知某样东西准备成为一个基础类,那么第一个选择应是将其变成一个interface（接口）。
只有在不得不使用方法定义或者成员变量的时候,才需要将其变成一个abstract（抽象）类。
接口主要描述了客户希望做什么事情,而一个类则致力于（或允许）具体的实施细节。
（19）在构建器内部,只进行那些将对象设为正确状态所需的工作。
尽可能地避免调用其他方法,因为那些方法可能被其他人覆盖或取消,从而在构建过程中产生不可预知的结果（参见第7章的详细说明）。
（20）对象不应只是简单地容纳一些数据;它们的行为也应得到良好的定义。
（21）在现成类的基础上创建新类时,请首先选择"新建"或"创作"。
只有自己的设计要求必须继承时,才应考虑这方面的问题。
若在本来允许新建的场合使用了继承,则整个设计会变得没有必要地复杂。
（22）用继承及方法覆盖来表示行为间的差异,而用字段表示状态间的区别。
一个非常极端的例子是通过对不同类的继承来表示颜色,这是绝对应该避免的:
应直接使用一个"颜色"字段。
（23）为避免编程时遇到麻烦,请保证在自己类路径指到的任何地方,每个名字都仅对应一个类。
否则,编译器可能先找到同名的另一个类,并报告出错消息。
若怀疑自己碰到了类路径问题,请试试在类路径的每一个起点,搜索一下同名的.class文件。
（24）在Java1.1AWT中使用事件"适配器"时,特别容易碰到一个陷阱。
若覆盖了某个适配器方法,同时拼写方法没有特别讲究,最后的结果就是新添加一个方法,而不是覆盖现成方法。
然而,由于这样做是完全合法的,所以不会从编译器或运行期系统获得任何出错提示--只不过代码的工作就变得不正常了。
（25）用合理的设计方案消除"伪功能"。
也就是说,假若只需要创建类的一个对象,就不要提前限制自己使用应用程序,并加上一条"只生成其中一个"注释。
请考虑将其封装成一个"独生子"的形式。
若在主程序里有大量散乱的代码,用于创建自己的对象,请考虑采纳一种创造性的方案,将些代码封装起来。
（26）警惕"分析瘫痪"。
请记住,无论如何都要提前了解整个项目的状况,再去考察其中的细节。
由于把握了全局,可快速认识自己未知的一些因素,防止在考察细节的时候陷入"死逻辑"中。
（27）警惕"过早优化"。
首先让它运行起来,再考虑变得更快--但只有在自己必须这样做、而且经证实在某部分代码中的确存在一个性能瓶颈的时候,才应进行优化。
除非用专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。
性能提升的隐含代价是自己的代码变得难于理解,而且难于维护。
（28）请记住,阅读代码的时间比写代码的时间多得多。
思路清晰的设计可获得易于理解的程序,但注释、细致的解释以及一些示例往往具有不可估量的价值。
无论对你自己,还是对后来的人,它们都是相当重要的。
如对此仍有怀疑,那么请试想自己试图从联机Java文档里找出有用信息时碰到的挫折,这样或许能将你说服。
（29）如认为自己已进行了良好的分析、设计或者实施,那么请稍微更换一下思维角度。
试试邀请一些外来人士--并不一定是专家,但可以是来自本公司其他部门的人。
请他们用完全新鲜的眼光考察你的工作,看看是否能找出你一度熟视无睹的问题。
采取这种方式,往往能在最适合修改的阶段找出一些关键性的问题,避免产品发行后再解决问题而造成的金钱及精力方面的损失。
（30）良好的设计能带来最大的回报。
简言之,对于一个特定的问题,通常会花较长的时间才能找到一种最恰当的解决方案。
但一旦找到了正确的方法,以后的工作就轻松多了,再也不用经历数小时、数天或者数月的痛苦挣扎。
我们的努力工作会带来最大的回报（甚至无可估量）。
而且由于自己倾注了大量心血,最终获得一个出色的设计方案,成功的快感也是令人心动的。
坚持抵制草草完工的诱惑--那样做往往得不偿失。
升级会员 