[align=center]良好编程习惯的养成[/align]
[align=center]——写给计算机系大学生[/align]
作者：深深爱你 QQ：66557239 http://hi.baidu.com/66557239
关键字 编程习惯 代码风格 初始化 代码注释 兼容性 健壮性 高效性
背景
最近，单位与省内某高校做校企合作，安排我去学校讲实践课。凑着这个机会，我把自己几年的一线开发经验拿出来给大家分享，特别是那些即将加入编程行列的同学，希望能把我的一些经验，能够让他们在开始的时候就能接触到，继而养成一种习惯，自然的应用在今后的研发工作中。
不少同学对语言的重视超出了我的想象，这使我不得不先说一下。这几乎是个经典问题了，不仅仅是学生，据我所知，不少论坛上也有诸如此类的问题。我始终认为，语言仅仅只是一个工具，不同的应用选择不同的工具。不要被语言所束缚，你应该去驾驭这些工具。
本人的看家语言Delphi，用Delphi做过UDP通信、数据库开发、底层视频采集等；
用F-Basic开发过小学数学出题系统；
通过Visual Fox Pro之二级等级考试；
用C语言描述过非对称加密算法，通过国家计算机等级考试(网络技术)三级机试语言；
用Asp+HTML做过网站，写过简单的JavaScript脚本；
用Visual Basic.net开发过MIS系统；
用c#.net做过用户注册功能；
用VC++调用过Delphi的dll，做DirectShow将C++代码看懂，然后用Delphi描述；
用Access的VBA调用过Delphi的dll，写过VBA脚本；
用标准SQL语言写过SQL语句；
最近，正在看JAVA之JSP相关的Web开发技术；
我曾经在我的博客(http://hi.baidu.com/66557239) 内打过个比方：如果你有一口宝刀，你应该首先把这刀法炼好；如果你已经炼就了盖世刀法，有一天需要用枪了，凭你的心智，可能枪拿起来你就会用，而且不久又会成为一个枪神；有一天需要用炮了，依你对武器的理解，…… 不同的应用，选择不同的工具，一定要对某一种工具有很深的理解，这样才能触类旁通，以不变应万变。
接下来，我就结合自己多年的一线开发经验，给大家谈谈一些心得体会，希望大家能够将这些转化为自己的东西，养成为一种习惯，那么笔者的目标也就实现了。
第一，培养写码的美感；写出来的代码，应该给人以整体的美的感受，看起来很整洁，让人愿意看，愿意细细研究；一个项目，应该有一个统一的编码规范，团队成员在写码的时候都遵循这个规范，如果做的很好的话，整个项目下来，应该就像是一个人在写码；这样团队内的任何成员拿到代码都可能感觉这代码是似曾相识，为今后的维护是有很大好处的；当然，如果我们没有一个统一的规范，一个连思路都很模糊的程序员，如果让他写出整洁的代码，可能是一种奢望，如此看来，优秀的代码也是技术成熟的一种表现。
第二，初始化；我所说的初始化，首先是指一个一个具体的变量的初始化。我可以确定的是：Delphi、C/C++、C#、JAVA这几种语言，所声明的变量，均要初始化后才可以使用。用户声明一个变量后，就会在内存中自动分配一块空间给这个变量。被分配的空间之前可能有数据，因此变量定义后如果不指定其值，那么在程序运行过程中其值是不可预知的，这将可能影响到程序的正常运行，甚至造成一些软件问题，而且很难被测试重现，这在我实际的工作中，是遇到过的。然后，我要指出的是，要注意一个函数/过程、一个功能、一个模块的初始化。我们举个例子，如果我们要写一个用户信息管理的模块，那么我们首先要对这个模块进行初始化，这个初始化根据不同的系统要求，可能内容不同，比如模块内的全局变量的初始化、界面上的栏位初始化、界面的状态初始化等等；
第三，创建与释放的严格对应；在Delphi、C/C++中，这里特指那些自己创建的对象、自己申请的内存空间，都要自己来释放；当然，在C#中，由于.net采用了代码托管，而.net有垃圾回收机制，一般情况下，你创建的对象不需要你关心回收问题；JAVA与C#一样，JAVA有JVM来处理垃圾回收问题，不需要你过多的关心；
第四，智慧注释；在代码注释这一块，一直有两种不同的观点，一种支持每段代码后面最好均加以注释；另一种支持无注释代码，认为需要注释的代码本身就是有问题的代码，真正在逻辑上清晰的代码，是不需要注释的；我个人比较倾向于后一种，但是我又反对一句代码都不加，所以我提倡“智慧注释”。所谓智慧注释，就是通常情况下，尽最大可能的保持逻辑的清晰，让其他伙伴很轻松的就能够看清代码的意图、功能，然后在关键的部分加上注释，什么是关键的部分呢？比如某个地方用到了一个公式，那么就得把此公式给写出来，某个地方容易出错，就要把注意写清楚等等。
第五，高内聚、低耦合；保持函数（过程）、单元、功能模块、项目的最大的独立性；注意划分函数/过程、单元、功能模块等的粒度问题。举个例子，比如，我们划分函数/过程，那么尽可能让一个独立的小功能写在一个函数/过程内。往大了想，比如单元、功能模块、项目等都是一样，尽可能提高内聚性，降低单元与单元之间、模块与模块之间的耦合性。如果这一点我们能够做的很好，比如模块与模块之间均采用接口的方式耦合，那么如果其中一个模块的功能有较大的调整，那么没有问题，我们只需要保持接口不变，调整这个模块的内部实现就可以了，而不会影响与其它模块之间的耦合。
第六，兼容性；关于兼容性，我主要谈三个方面：1、SQL语句的兼容性；由于我们的系统可能需要同时使用Microsoft的SQL Server和Postgres的PgSQL，甚至可能要求支持Access，所以我们在写SQL语句的时候，就要考虑书写通用的SQL语句，而不能写任一数据库所特有的写法；如果这一点做的很好，我们可以根据用户的规模或者要求，非常灵活的更换对不同数据库的支持；2、不同软硬件环境的兼容性；我觉得这一点，Microsoft可以算得上是典范，其Windows软件几乎可以在任何可以装起来的机器上有很好的表现。就拿我最近发现的windows的一个长处来说吧，我的显示器换宽屏了，这时我才发现，windows窗口对内容的显示是可以支持宽屏的，而且效果很好，相比之下，不能充分利用宽屏的一些网站表现就很差了，包括一些桌面软件的表现也不尽人意，当然，这一点我也承认，自己设计的软件也没有充分考虑或者没有很好的解决这个问题；3、软件的向下兼容；这个说起来大家都知道是什么意思，但是一到实际应用中，就会很容易被忽略，我最近就遇到过这么一个问题。我利用面向对象技术写的一个功能模块，早期的版本，是不需要后台表中的某字段(iField)的，由于修改一个BUG，需要用到这个字段(iField)了。这时候，我只改了当前的功能，用了这个字段，但是没有考虑到，以前的版本，用户现在手上正在使用的版本，这个字段(iField)可能并没有值（因为之前是用不到的），这就出现了向后兼容的问题。
第七，健壮性；关于健壮性，就是程序即使出现的非常严重的问题，也不要出现没有响应、软件崩溃等让用户恼火的现象，我认为应该养成习惯，在容易出现致命问题的地方，我们要主动写代码去捕捉这些异常，即便这些异常意外的发生了，我们也可以给用户一个友好的提示，而不至于整个软件“挂掉”，当然，我们要最大可能的避免出现这些异常。
第八，高效性；让自己的程序飞起来。关于高效性，我主要想从表结构设计，业务操作，代码优化三方面谈谈。首先，我认为表结构设计不仅仅要完成其存储数据的功能，而且要考虑表结构设计的高效性与简洁性，在这里，主要说一下高效性。这个高效性包括传输的高效性和保存的高效性，传输的高效性，主要是指，单位时间内，能够将较多的信息由数据库传送至软件内(可能是LAN或者WAN)；保存的高效性，主要是指，存储相当的信息量，所用的时间最短。这里有一个指导思想，用尽可能少的信息符号来传达完整的信息。举个例子，比如我写的BUG管理系统，里面有一张表(tbbuginfo)，用于存储BUG的属性信息。 BUG的属性包括编号、名称、严重性、优先级别、所属项目、提交人等，通常情况下，我们是把这些信息直接写入表内就是；但是如果按照上面的指导思想去考虑，像严重性、优先级别、所属项目、提交人这类信息，我们都可以把他们做成基本资料，然后用一个编号与之对应，这样我们在保存和传输的时候，只需要传输这些编号即可，大大提高了效率。其次，如果有可能，我们在设计表的时候，可以考虑业务上的需要，比如，需要操作的频度非常大的表，我们尽可能将其做的简单，信息量做到最精简，如果需要更详细的信息，我们再去关联表中取详细信息；这样做的好处在于，需要频繁操作的表，响应速度、查询速度都会非常快；最后说一下代码优化，现在我们的机器配置在不断的上升，就说内存吧，现在1G的内存已经是标配了，2G的内存也很常见，所以在我们写代码的时候，可以考虑利用这些内存，去换取时间，而不是一味地尽可能减小内存占用。我还是说说我写的BUG管理系统里面的一个典型写法，在系统启动的时候，我把诸如严重性、优先级别、项目名称等这些相对固定的内容读入到内存中，然后软件在任何需要通过编号显示名称的地方，直接从内存中读取这些信息，这个时间几乎可以忽略不计，效率提高了 N倍。
[color=red]最后的忠言 戒骄戒躁 夯实基础 高标准 高要求 争取一切实战机会[/color]
不要浮躁，沉下心来，把基础打好，把理论性的东西学透，然后应用于实践，在实践中煅炼、成长；提高对自己的要求，这些要求可以到一些招聘网站上查询得到，比如某职位招人，需要什么样的技能，到什么程度，自己经常性的去对比一下自己，还有多少差距，找出不足，继续努力；另外，还要珍惜一切实战的机会，只要有机会就不要错过，没有机会，自己创造机会，有时间可以自己做个小项目出来，这个项目的要求越高，只要你最终实现了，那么你提高的就越多。
以上籍由自己多年的一线开发经验，给大家说说，希望大家可以从中受益，让一些我们日常工作中遇到的问题，在大家的身上不再重现，养成良好的习惯，说大点，也为国内的软件业发展尽一份微薄之力吧。
[align=right]
作者：深深爱你
2008年12月29日夜书于蚌埠[/align]
[align=center]——写给计算机系大学生[/align]
作者：深深爱你 QQ：66557239 http://hi.baidu.com/66557239
关键字 编程习惯 代码风格 初始化 代码注释 兼容性 健壮性 高效性
背景
最近，单位与省内某高校做校企合作，安排我去学校讲实践课。凑着这个机会，我把自己几年的一线开发经验拿出来给大家分享，特别是那些即将加入编程行列的同学，希望能把我的一些经验，能够让他们在开始的时候就能接触到，继而养成一种习惯，自然的应用在今后的研发工作中。
不少同学对语言的重视超出了我的想象，这使我不得不先说一下。这几乎是个经典问题了，不仅仅是学生，据我所知，不少论坛上也有诸如此类的问题。我始终认为，语言仅仅只是一个工具，不同的应用选择不同的工具。不要被语言所束缚，你应该去驾驭这些工具。
本人的看家语言Delphi，用Delphi做过UDP通信、数据库开发、底层视频采集等；
用F-Basic开发过小学数学出题系统；
通过Visual Fox Pro之二级等级考试；
用C语言描述过非对称加密算法，通过国家计算机等级考试(网络技术)三级机试语言；
用Asp+HTML做过网站，写过简单的JavaScript脚本；
用Visual Basic.net开发过MIS系统；
用c#.net做过用户注册功能；
用VC++调用过Delphi的dll，做DirectShow将C++代码看懂，然后用Delphi描述；
用Access的VBA调用过Delphi的dll，写过VBA脚本；
用标准SQL语言写过SQL语句；
最近，正在看JAVA之JSP相关的Web开发技术；
我曾经在我的博客(http://hi.baidu.com/66557239) 内打过个比方：如果你有一口宝刀，你应该首先把这刀法炼好；如果你已经炼就了盖世刀法，有一天需要用枪了，凭你的心智，可能枪拿起来你就会用，而且不久又会成为一个枪神；有一天需要用炮了，依你对武器的理解，…… 不同的应用，选择不同的工具，一定要对某一种工具有很深的理解，这样才能触类旁通，以不变应万变。
接下来，我就结合自己多年的一线开发经验，给大家谈谈一些心得体会，希望大家能够将这些转化为自己的东西，养成为一种习惯，那么笔者的目标也就实现了。
第一，培养写码的美感；写出来的代码，应该给人以整体的美的感受，看起来很整洁，让人愿意看，愿意细细研究；一个项目，应该有一个统一的编码规范，团队成员在写码的时候都遵循这个规范，如果做的很好的话，整个项目下来，应该就像是一个人在写码；这样团队内的任何成员拿到代码都可能感觉这代码是似曾相识，为今后的维护是有很大好处的；当然，如果我们没有一个统一的规范，一个连思路都很模糊的程序员，如果让他写出整洁的代码，可能是一种奢望，如此看来，优秀的代码也是技术成熟的一种表现。
第二，初始化；我所说的初始化，首先是指一个一个具体的变量的初始化。我可以确定的是：Delphi、C/C++、C#、JAVA这几种语言，所声明的变量，均要初始化后才可以使用。用户声明一个变量后，就会在内存中自动分配一块空间给这个变量。被分配的空间之前可能有数据，因此变量定义后如果不指定其值，那么在程序运行过程中其值是不可预知的，这将可能影响到程序的正常运行，甚至造成一些软件问题，而且很难被测试重现，这在我实际的工作中，是遇到过的。然后，我要指出的是，要注意一个函数/过程、一个功能、一个模块的初始化。我们举个例子，如果我们要写一个用户信息管理的模块，那么我们首先要对这个模块进行初始化，这个初始化根据不同的系统要求，可能内容不同，比如模块内的全局变量的初始化、界面上的栏位初始化、界面的状态初始化等等；
第三，创建与释放的严格对应；在Delphi、C/C++中，这里特指那些自己创建的对象、自己申请的内存空间，都要自己来释放；当然，在C#中，由于.net采用了代码托管，而.net有垃圾回收机制，一般情况下，你创建的对象不需要你关心回收问题；JAVA与C#一样，JAVA有JVM来处理垃圾回收问题，不需要你过多的关心；
第四，智慧注释；在代码注释这一块，一直有两种不同的观点，一种支持每段代码后面最好均加以注释；另一种支持无注释代码，认为需要注释的代码本身就是有问题的代码，真正在逻辑上清晰的代码，是不需要注释的；我个人比较倾向于后一种，但是我又反对一句代码都不加，所以我提倡“智慧注释”。所谓智慧注释，就是通常情况下，尽最大可能的保持逻辑的清晰，让其他伙伴很轻松的就能够看清代码的意图、功能，然后在关键的部分加上注释，什么是关键的部分呢？比如某个地方用到了一个公式，那么就得把此公式给写出来，某个地方容易出错，就要把注意写清楚等等。
第五，高内聚、低耦合；保持函数（过程）、单元、功能模块、项目的最大的独立性；注意划分函数/过程、单元、功能模块等的粒度问题。举个例子，比如，我们划分函数/过程，那么尽可能让一个独立的小功能写在一个函数/过程内。往大了想，比如单元、功能模块、项目等都是一样，尽可能提高内聚性，降低单元与单元之间、模块与模块之间的耦合性。如果这一点我们能够做的很好，比如模块与模块之间均采用接口的方式耦合，那么如果其中一个模块的功能有较大的调整，那么没有问题，我们只需要保持接口不变，调整这个模块的内部实现就可以了，而不会影响与其它模块之间的耦合。
第六，兼容性；关于兼容性，我主要谈三个方面：1、SQL语句的兼容性；由于我们的系统可能需要同时使用Microsoft的SQL Server和Postgres的PgSQL，甚至可能要求支持Access，所以我们在写SQL语句的时候，就要考虑书写通用的SQL语句，而不能写任一数据库所特有的写法；如果这一点做的很好，我们可以根据用户的规模或者要求，非常灵活的更换对不同数据库的支持；2、不同软硬件环境的兼容性；我觉得这一点，Microsoft可以算得上是典范，其Windows软件几乎可以在任何可以装起来的机器上有很好的表现。就拿我最近发现的windows的一个长处来说吧，我的显示器换宽屏了，这时我才发现，windows窗口对内容的显示是可以支持宽屏的，而且效果很好，相比之下，不能充分利用宽屏的一些网站表现就很差了，包括一些桌面软件的表现也不尽人意，当然，这一点我也承认，自己设计的软件也没有充分考虑或者没有很好的解决这个问题；3、软件的向下兼容；这个说起来大家都知道是什么意思，但是一到实际应用中，就会很容易被忽略，我最近就遇到过这么一个问题。我利用面向对象技术写的一个功能模块，早期的版本，是不需要后台表中的某字段(iField)的，由于修改一个BUG，需要用到这个字段(iField)了。这时候，我只改了当前的功能，用了这个字段，但是没有考虑到，以前的版本，用户现在手上正在使用的版本，这个字段(iField)可能并没有值（因为之前是用不到的），这就出现了向后兼容的问题。
第七，健壮性；关于健壮性，就是程序即使出现的非常严重的问题，也不要出现没有响应、软件崩溃等让用户恼火的现象，我认为应该养成习惯，在容易出现致命问题的地方，我们要主动写代码去捕捉这些异常，即便这些异常意外的发生了，我们也可以给用户一个友好的提示，而不至于整个软件“挂掉”，当然，我们要最大可能的避免出现这些异常。
第八，高效性；让自己的程序飞起来。关于高效性，我主要想从表结构设计，业务操作，代码优化三方面谈谈。首先，我认为表结构设计不仅仅要完成其存储数据的功能，而且要考虑表结构设计的高效性与简洁性，在这里，主要说一下高效性。这个高效性包括传输的高效性和保存的高效性，传输的高效性，主要是指，单位时间内，能够将较多的信息由数据库传送至软件内(可能是LAN或者WAN)；保存的高效性，主要是指，存储相当的信息量，所用的时间最短。这里有一个指导思想，用尽可能少的信息符号来传达完整的信息。举个例子，比如我写的BUG管理系统，里面有一张表(tbbuginfo)，用于存储BUG的属性信息。 BUG的属性包括编号、名称、严重性、优先级别、所属项目、提交人等，通常情况下，我们是把这些信息直接写入表内就是；但是如果按照上面的指导思想去考虑，像严重性、优先级别、所属项目、提交人这类信息，我们都可以把他们做成基本资料，然后用一个编号与之对应，这样我们在保存和传输的时候，只需要传输这些编号即可，大大提高了效率。其次，如果有可能，我们在设计表的时候，可以考虑业务上的需要，比如，需要操作的频度非常大的表，我们尽可能将其做的简单，信息量做到最精简，如果需要更详细的信息，我们再去关联表中取详细信息；这样做的好处在于，需要频繁操作的表，响应速度、查询速度都会非常快；最后说一下代码优化，现在我们的机器配置在不断的上升，就说内存吧，现在1G的内存已经是标配了，2G的内存也很常见，所以在我们写代码的时候，可以考虑利用这些内存，去换取时间，而不是一味地尽可能减小内存占用。我还是说说我写的BUG管理系统里面的一个典型写法，在系统启动的时候，我把诸如严重性、优先级别、项目名称等这些相对固定的内容读入到内存中，然后软件在任何需要通过编号显示名称的地方，直接从内存中读取这些信息，这个时间几乎可以忽略不计，效率提高了 N倍。
[color=red]最后的忠言 戒骄戒躁 夯实基础 高标准 高要求 争取一切实战机会[/color]
不要浮躁，沉下心来，把基础打好，把理论性的东西学透，然后应用于实践，在实践中煅炼、成长；提高对自己的要求，这些要求可以到一些招聘网站上查询得到，比如某职位招人，需要什么样的技能，到什么程度，自己经常性的去对比一下自己，还有多少差距，找出不足，继续努力；另外，还要珍惜一切实战的机会，只要有机会就不要错过，没有机会，自己创造机会，有时间可以自己做个小项目出来，这个项目的要求越高，只要你最终实现了，那么你提高的就越多。
以上籍由自己多年的一线开发经验，给大家说说，希望大家可以从中受益，让一些我们日常工作中遇到的问题，在大家的身上不再重现，养成良好的习惯，说大点，也为国内的软件业发展尽一份微薄之力吧。
[align=right]
作者：深深爱你
2008年12月29日夜书于蚌埠[/align]
扫一扫
1886
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
