初级软件开发工程师：养成良好的编码习惯

        编写程序是一项系统而繁琐的工作，它不仅需要程序设计人员基础扎实，更需要有良好的编程习惯和风格。良好的编程习惯和风格不仅可以使程序代码更易于读懂和修改，更重要的是，它可以使程序的结构更加合理，有助于提高程序的执行效率，能提高设计软件的质量。下面是我总结的一些经验，与大家分享：

　   我们大部分程序员编写一个程序，总是要先进行一番构思，然后就一边写代码一边调试。可是，这种方法一般只适用于非常小的程序，根据软件工程的特点，如果对所有程序都还按这种方法进行设计，是很不合理的。设计程序就像我们大楼，首先要设计图纸，然后才动工。所以，对于个人编写程序来说，基本应该遵循以下步骤：

　　1、问题分析：对我们要使用程序设计手段去解决的问题进行系统地分析，了解程序是要做什么，要达到一种什么样的效果等。

　　2、结构设计：也就是对程序的整体框架进行设计，设计出我们需要使用的模块等等，并画出流程图（当然现在公司里边一般分工都很明确，一般有架构师来设计整体框架，但是我想我们每一个程序员也不会仅仅想一辈子做程序员吧！）

　　3、用户界面设计：在此，我们要设计出用于与用户交互的输入输出界面。（尽管在软件开发中界面是由美工来完成的）

　　4、代码设计：在这个步骤中，我们要进行代码的编写。（程序员往进去填写代码，但不是就是让你复制黏贴噢）

　　5、调试：对程序中正在发生或可能发生的各种错误进行处理。（软件测试工程师，有专门的测试工具，编写测试脚本）

　　6、维护：通俗地说，维护就是对程序进行升级，对原有错误进行修改。（运维）

　　对于以上几个步骤，我想大多数人会认为代码设计最为重要，但如果程序的结构尚未清楚，我们在编写代码的时候就会发生混乱，一个程序性能的好坏，主要还是取决于它的结构是否合理。因序设计中，我们要尽可能注意这一点，这样才能使我们的程序更加完善。

　设计环境

　　一个良好的编程环境可以使我们在编写程序时，不至于造成各种资源的混乱，还可以避免资源的浪费。建议大家要在放源程序的目录下建立“Programs”文件夹；然后再以你要编写的程序名和版本为名建立一个文件夹，用于存放整个源程序以及各种资源；最后，分别建立几个文件夹，“Documents”：用于存放程序文档，包括流程图等；“Resource”：用于存放图片，声音，影片等资源；“Debug”：用于存放调试的程序。“Release”：用于存放最终释放的程序。

  另外，最好再建立一个专门的文件夹，用于存放各种模块，以便能实现代码的重用，这样，我们就不用在每次写程序时，都重写所有的模块，编程速度会有很大的提高。

　设计技巧

　　代码如果写得很乱，程序便不易被阅读与修改，所以，在编写代码时要注意以下几点：

　　(1)注释：写注释虽然要占用一定的时间，但在阅读和修改代码时却会节省很多的时间。所以，建议大家在定义一个函数时，在函数的第一行写出函数的作用，再用一行解释函数的参数，并在每个变量的定义语句后注释出其作用。

　　(2)变量和函数的命名：每个程序都会使用很多的变量和函数，如果随意命名变量与函数，每次使用时还得在变量或函数的定义语句处查出它的数据类型及名称，而且随意命名还会造成变量与函数重复定义。

　　建议大家使用匈牙利命名法，方法是：每个变量或函数的开头都以其数据类型的缩写命名，然后再加上代表这个变量或函数的作用的英文单词简写共同组成变量或函数的名称。例如：要定义用于计数的整型变量count，其定义语句为java：int icount;。以这种方法定义，不仅可以有效地避免变量与函数的混乱与重复定义，还可以保证数据类型的匹配。

　　(3)控件命名：如果在Windows下编程，你有可能会大量地使用控件，如果不对控件名严加管理，会造成很大程度的混乱，因此，建议在给控件命名时，以控件类型缩写再加上代表这个控件作用的英文单词的简写共同组成此控件的名称。例如：你要命名一个按钮控件，作用是进行删除操作，那么控件名可以命名为cmdDel。

  以下是一些总结技巧：

1.避免将多个类放在一个文件里面； 

2.一个文件应该只有一个命名空间，避免将多个命名空间放在同一个文件里面;

3. 一个文件最好不要超过500行的代码（不包括机器产生的代码);

4. 一个方法的代码长度最好不要超过25行;

5. 避免方法中有超过5个参数的情况。使用结构来传递多个参数;

6. 每行代码不要超过80个字符;

7. 不要手工的修改机器产生的代码;
        ( a)  如果需要编辑机器产生的代码，编辑格式和风格要符合该编码标准;

       ( b)  Use partial classes whenever possible to factor out the maintained portions. 

8. 避免利用注释解释显而易见的代码。

     (a)  代码应该可以自解释(好的代码由可读的变量和方法命名因此不需要注释);

9.  Document only operational assumptions, algorithm insights and so on.   

10.  避免使用方法级的文档。

    (a)  使用扩展的API文档说明之。

   （b)  只有在该方法需要被其他的开发者使用的时候才使用方法级的注释。（在C#中就是///）

11.  不要随便使用final，构造一般用函数设定其值。只有固定的不改变的值才设为静态变量，比如一个星期的天数；

12. 代码的每一行都应该通过白盒方式的测试;

13.  只抛出已经显示处理的异常。

14.  在捕获(catch)语句的抛出异常子句中(throw)，总是抛出原始异常维护原始错误的堆栈分配。

catch(Exception exception) 

{    

    MessageBox.Show(exception.Message); 

    throw ;  //和throw exception一样。 

} 

15. 避免方法的返回值是错误代码。

16.  尽量避免定义自定义异常类，当需要定义自定义的异常时：用面向对象的理论(而不是结论)，照搬结论不一定能提到质量或效率，可能适得其反；

 

 

下面是我自己的一些心得：        

          1.面向对象可以是面向对象特征(属性)，也可以是面向服务(方法)，服务要比特征更加稳定；
          2.降低耦合(隔离)，我认为耦合分为代码耦合和工序耦合，通常构建了一大堆对象,结果并没有感到轻松,往往代码弱耦合了，工序强耦合了；
例如方法的参数设计成了类,参数是减少了(调用接口也变得稳定了,这就是代码耦合降低了)，可是如果不借助文档,程序员很难弄清方法需要什么又改变了什么(工序耦合增加了)，开发项目时时这种情况，后期维护就更不用说了。应该使用代码自动化降低代码耦合，增加自动化工序降低手工工序减少工序耦合；
         3.面向修改封闭，面向扩展开放。设计应该尽可能以不修改原有代码的方式满足需求变更，通过代码自动化以替换方式代替修改方式改进项目；
         4.MVC三层开发体系中：从M层驱动是最差的驱动方式，从C层驱动是最佳驱动方式，这跟前面的第一点是相辅相成的。

           

 总之，在开发过程中，软件文档、需求分析、概要设计和详细设计要齐全。 文档齐全了，后期维护和完善就比较容易，我认为这是最重要的。 代码编写要符合一定的规范； 注释一般要占代码行数的20%； 每个函数最好不要超过100行； 并且对函数的输入输出使用等方面要有注释。你可以看看 ”软件工程“ 方面的书籍，会对你很有帮助的。

　　并不是每个人都能够成为顶级程序员，但我们都在程序员之路上要不断进步，追求更完美、更专业化的程序。不妨尝试着改变一下，会让你受益多多！