IT人士的职业规范——凝视


这两天将系统敲完了，该总体调试了，调试的过程中，发现了一个非常大的问题，就是自己的凝视写的不够，有时候不明确U层这个事件是做什么的，有时候不知道这个事件传递的是什么參数，有时候不知道相应的B层和D层是哪个，相应的B和D各做了什么工作。………….所以有的时候就须要自己从头到尾在看一遍代码，看一下传递了什么參数。看这些參数，是做什么用的，看一下，相应的B层对返回的数据做了什么处理，看一下相应的D层。起了什么作用。

这个时候这个过程真的非常浪费时间，让自己有一种非常厌烦的感觉。

这是自己的代码，自己编写，自己调试。就有这种感觉了，假设让你去调试别人的这种代码，那别人又该有什么样的感觉那？？是不是要吐了啊？？

所以说在这个小程序中我是深深的体会到了代码凝视的重要性。

想了一下当时自己为什么没有编写凝视，结合曾经米老师讲的课。整理了一下。

①写凝视太费时间。

实际上，在编写代码时加上凝视根本不须要多少时间。当时是趁热打铁，对于那些代码理解比較通透，写一句凝视就是敲那几个字的时间。

可是假设后来在加入凝视，就不只要敲那几个字，还要在从新理解一下这一块的代码。甚至相关的代码。假设后来不谢凝视，那么等到调试的时候就会像上面说的一样了啊。

②有些过程非常难凝视。

通常而言，假设代码的一个部分非常难凝视，那么假设没有凝视，其它人就更难理解你的代码。自己理解不清楚。怎么会使别人也理解清楚那。

③复杂而非常难凝视的代码或许不是什么好代码。假设你发现难以给所有或部分过程加上凝视，那么请回头好好观察一下你的代码,你会发现更好的解决的方法。

所以，凝视不是代码的附属品，它与代码是共存的关系。

凝视就是对代码的解释和说明。

目的是为了让别人和自己非常easy看懂。为了让别人一看就知道这段代码是做什么用的。代码凝视有几类

①行尾凝视

就是每行代码末尾的凝视。这些凝视仅仅能用于较短的描写叙述。比方变量。

②内部凝视

内部凝视是最经常使用和最重要的凝视。使用内部凝视可以说明过程的实现方法。使读者可以顺利通过各个不同的转折。

如：IF语句、Select Case语句、循环语句、全局变量、重要的变量。内部凝视将故意于理解这些代码。

③凝视标头。

在模块、类、属性、方法前一行加入凝视，以便调用的时候提示用户。凝视标头能够包括多个文字项，比方输入參数、返回值、原始作者、最后编辑该过程的程序猿、上次改动日期、版权信息，甚至包括程序猿喜欢的颜色。

每一个凝视表头应该有统一的格式。这个我们的net代码规范中已经做了规范了。

当然为了使我们的凝视看起来不是非常乱，增强凝视的可读性。

①易理解-----凝视是供人阅读的，而不是让计算机阅读的。应该使凝视便于人们理解。难以理解的凝视不如不写。

②另外，凝视属于文字信息。（用汉语翻译过来，自己的话说出来）---正如应用程序的文字信息，必须清楚地书写一样，代码凝视也应该遵循好的书写规则。比方：使用比較完整的语句来描写叙述。不要使用缩写。

③书写---凝视通常位于它们要说明的代码的前面。为了从视觉上突出凝视与它的代码之间的关系，请将凝视缩进，使之与代码处于同一个层次上。

上面已经写了，凝视的种类，凝视的格式。那么应该对什么进行凝视那？

种类	说明
类、过程、方法	描写叙述其的用途（而不是事实上现方式）、參数、返回值
输入	输入參数的作用
输出	说明过程返回的值，及其代表的意义
变量	尤其是全局变量，作用范围

这些凝视的种类自己在写程序中觉得应该加入的。如有什么不足，请指出。

用文字说明代码的作用，简单地反复代码做些什么。这种凝视差点儿不能给代码添加什么信息，（这句感觉自己理解不是非常到位）

凝视能使代码更加easy理解。更加easy跟踪。出色的凝视就像一幅好的设计蓝图，可以引导阅读者通过你的应用程序的曲折之处，可以说明预期的执行结果和可能出现的异常情况。

当然眼下自己还是没有达到这样的程度，越写感觉自己越不懂。哎…………….