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

时间:2023-11-12 20:31:50


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

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

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

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

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

①写凝视太费时间。

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

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

②有些过程非常难凝视。

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

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

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

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

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

①行尾凝视

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

②内部凝视

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

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

③凝视标头。

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

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

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

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

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

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

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

种类

说明

类、过程、方法

描写叙述其的用途(而不是事实上现方式)、參数、返回值

输入

输入參数的作用

输出

说明过程返回的值,及其代表的意义

变量

尤其是全局变量,作用范围

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

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

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

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