分类目录

链接

2012年八月
« 7月   9月 »
 12345
6789101112
13141516171819
20212223242526
2728293031  

近期文章

热门标签

博主推荐

现在位置:    首页 > Others > 正文
如何养成好的代码书写习惯
Others 评论(1) 阅读(1,967)

1.什么样的代码是可读性好的代码?

“让人阅读你的代码,就像阅读文章一样流畅!”——这就是好代码!

把代码当作一篇优美的散文来写!用这样的标准来要求自己,一定会写出好代码,一定会成为一个优秀的程序员。

代码不仅是写给机器编译的,更是写给人看的!

代码不仅是代码,更是文档!
2.先写注释,再写代码;理清思路再动手

清晰的思路是编程行动的良好指南。花点时间思考一下,不要一接到任务就动手编代码,从而陷入技术细节不可自拔。

我一般这样编程:

(1)在一个空的函数体内用注释写出自己的思路,如:

//功能说明:XXX

private void MyMainFunction()

{

//第一步,XXX

//第二步,XXX

MySubFunction ();//实现XXX

//第三步,XXX

}

//功能说明:XXX

private void MySubFunction()

{

}

(2)理清思路后,在空白处填写自己的代码。

如果某个步骤中实现起来感觉有点麻烦,那就先放一个空的子函数,为这个子函数建一个空的函数体——保证编译始终通过,稍后再填充这个空函数体。这种方法不影响你的整体思路,避免陷入编程细节,同时又让“大事化小,小事化了”。

(3)编完主函数后,填充空的子函数体。

其实是对(1)(2)的迭代。通过主函数的运行效果,可以实时检测子函数编写的正确与否。我们编写的子函数都即时被应用场景所调用,也就是即时的被测试,这不也是测试驱动的思想吗?事实证明,这样得到的函数,比预先设计的函数更有用。

这样,只要思路清晰正确,编程就不会走太大弯路。

注释应先于代码存在,而不是编写完代码之后去补注释。因为人固有的懒惰,编写完代码之后都不情愿再去主动加注释,这使得代码的可读性变差。

因为大多数人都懒得加注释,所以我对初学者一般会要求每五行要有一行注释,总之是多多益善。矫枉必须过正!因为,减少注释是一件容易的事。有人会担心注释过多的问题,可是至今我还没有看到注释过多的情况。

另外,利用空白或空白行合理分隔代码,也是一种良好的注释。就像好的文章印刷时,段落间距要大一点是一样的。文章中也要留白!

使用region合理分隔代码,同时在region中加入注释。特别是,一定要把私有函数聚集到region中折叠起来,不要与公有函数(或事件函数)交叉,因为我们阅读代码往往是从公有函数(或事件函数)入手的。这可以隐藏细节,使代码看起来更整洁。
3.给变量起个好名字!

合理的变量命名是代码可读的基础。好的命名,不仅仅是使得代码易读,它代表了你对业务领域的理解,对程序逻辑的认知,对项目框架的把握。所以,好的程序员很多时候纠结的不是技术实现问题,而是如何为变量起一个好名字,使得代码读起来流畅,能让更多的人理解!

遵循一些成熟的命名规范,给变量起个好名字的事会容易一些。接下来,我们探讨一下常见的命名规范问题。

(1)常见的大小写命名法:

PascalCasing(大写开头):用于名字空间、类型、成员等的命名,举例:FileStream。

camelCasing(驼峰命名法,小写开头):用于形参、局部变量、私有字段等的命名。举例ToInt32(string value)。

匈牙利命名法(小写开头,首单词为数据类型):不推荐使用,因为IDE的智能提示很容易让你知道变量的类型。举例:intCount、iCount。

另外,微软建议不要在单词间使用下划线。

(2)名字空间的命名:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]。举例:

XuanyuanTech.RailwayMis.Web

(3)类(结构)及对象的命名:

名词或名词短语,因为它们代表系统中的实体。举例:

Student student;

List<Student> students;

(4)接口的命名:

表示类型层次的根基时:名词或名词短语,如:IList<T>;

表示某种能力时:形容词或形容词短语,如IComparable<T>。

(5)方法的命名:

动词或动词短语,DoSomething()。如:String.Split()

返回布尔值时使用表示肯定性的短语,并考虑第三人称。如:collection.Contains(item)

(6)属性的命名:

名词短语或形容词。举例:

public class ListView{

public ItemCollection Items {get;}//这里用复数形式

}

用肯定性短语命名布尔属性,考虑前缀“Is/Can/Has”。举例:CanRead、IsPostBack。

(7)控件的命名:

在ASP.NET MVC编程中是不需要这项规范的。

在WinForm、ASP.NET WebForm编程中,我喜欢使用匈亚利命名法给操控型控 件命名,操控型控件主要指菜单、按钮、树图等。如menuFile、menuFile_Open分别表示一个一级和二级菜单,btnFile_Open表 示一个按钮,这也避免了菜单和按钮功能相同时命名重复的尴尬。另外,如果你在IDE中输入一个menu,所有的菜单控件会按字母顺序在智能提示栏中整齐的 排列显示。IDE为按钮menuFile自动生成的点击事件函数命名为private void menuFile_Click(),这比File_Click()更好理解,因为在这里智能提示不能告诉你File是什么东东。

在添加或编辑界面中,会有大量的编辑型控 件(主要指文本框、下拉框等)与数据实体的属性对应。这时我们可以考虑使用统一的前缀e给这些控件命名,如编辑框eName对应实体对象的Name属 性,e在这里可以理解为entity或edit。使用统一的前缀e,为的就是在IDE中输入前缀后,其智能提示的内容与实体对象的属性提示保持顺序上的一 致,不被其它控件的名字插入而干扰对应的一致性。当然,如果使用自动化代码生成工具,也可以考虑不使用前缀。

这里,我们较多的考虑了IDE(特别是智能提示)对编程的影响。同时我们也看到IDE生成的事件函数名字并没完全遵守不使用下划线的约定。

命名规范不是一成不变的,在特定场景下可以有自己风格的约定,前提是要使代码保持一致、易读。比如,一般我们强烈反对使用汉语拼音命名变量,可是在有些项目中,特别是涉及国内政府、院校的信息标准时,其数据库字段(量很大)完全是按汉语拼音首字母制定的,如果非要翻译成英文就有点矫枉过正了(工作量本身也很大)。一旦熟悉了这个行业之后,这些汉语拼音简写也就成了业务领域知识的一部分了,也就不那么别扭了,这也算中国特色吧。
4.如何检测你的代码是否规范?

(1)人工检测:让同伴阅读你的代码(结对编程,代码复审),发现问题。自我检测,不懈追求――“让人阅读你的代码,就像阅读文章一样流畅!”。

(2)工具检测:FxCop,微软的一个开发工具,可以对编译过的托管代码进行分析,并告诉用户哪些地方不符合设计规范。
5.重构你的代码,做得更好一点点!

嗅嗅代码的坏味道:如果你发现在单页中写了过多的MySubFunction,如果你检测到不符合设计规范的代码,如果你写了过长的函数,如果你发现你在重复拷贝相同的代码段……是时候重构你的代码了!

何谓重构?重构是对软件内部结构的一种调整,目的是在不改变软件可察行为的前提下,提高其可理解性,降低其修改成本。

为何重构?改进软件设计(消除重复,Don’t Repeat Yourself);使代码更易理解(提高可读性);帮你找到Bug(Keep Your Code Clean);助你提高编程速度(后退是为了大踏步的前进)。

何时重构?三次法则:事不过三,三则重构。重构不是重构的目的,当重构能帮助你把后续的事情做得更好,那么还等什么?重构的时机:添加功能时,修补错误时,复审代码时。

如何重构?小步前进,不断验证。(Done Better Than Perfect)

常见的重构原因和对策:

(1)代码重复。提取为公共类/函数。

(2)代码形式重复。考虑模板类/泛型。

(3)过多函数的类。考虑使用partial分部类,将类分拆到多个文件中去,每个分部类对应一个文件。如MVC中Controller类往往会成为包含过多Action函数的类,就可将其按功能域拆分为多个分部类。

(4)过长的参数列表。构造一个对象,包含所有要用的参数,然后将这个对象当作参数即可。

编程的过程实际是一个不断重构(改进)的过程。通过不断重构,可以去除代码的坏味道,编写可读性更好的代码。同时也深化了你对设计的理解,提高了你的编程素养。

重构,是一种生活态度,每天做得更好一点点。不要有过多的期望,一点点就好!不断前进,逐步逼近完美。
6.向微软学习,向MSDN学习!

微软作为业界最为成功的软件生产商,在各方面都有值得我们学习的地方。我觉得Windows、Office等是我们做界面和为用户设计操作模式的最好老师,当我没有思路的时候,我都会打开Windows的某个功能看看,就会受到启发。

MSDN是 我们学习编程的最好老师。MSDN是众多大师的智慧结晶。经常看MSDN中的类库,不仅可以系统的掌握类库的功能,还可以学到如何给变量命名,如何进行架 构设计等。看MSDN中的示例代码,也是快速上手的捷径;特别是一些“快速指南”,能很快让你了解某个方面的开发技术。总之,看MSDN有百利而无一害, 呵呵,比看很多烂书强多了。

MSDN是帮助文档,我们在使用很多软件遇到问题时,是否忽略了开发者精心给我们准备的帮助文档呢?

---------------------

通过注释理清思路,给变量起好名字,重构你的代码,从MSDN中领悟大师真谛,其实都是一些编程习惯,养成好的、适合自己的习惯会受益终身。软件大师Kent Beck说:

“我不是个伟大的程序员,我只是个有着一些优秀习惯的程序员而已。”

——与诸君共勉!希望大家都成为具有优秀习惯的程序员,编写散文诗一样的代码!
7.推荐阅读

《.NET设计规范:约定、惯用法与模式》

《重构——改善既有代码的设计》

本文只是入门知识,未尽问题请参考这两本书,呵呵J

本文版权归数据库之家所有,转载引用请完整注明以下信息:
本文作者:Bruce
本文地址:如何养成好的代码书写习惯 | 数据库之家

如何养成好的代码书写习惯:目前有1 条留言

  1. 数据库之家 : 2012年09月25日下午 12:43 回复

    多看MSDN

发表评论

留言无头像?