oo第三次博客

1.规格化设计调研

Coding conventions for projectsApache Developers' C Language Style GuideDrupal PHP Coding StandardsZend Framework Coding StandardsGNU Coding StandardsStyle guides for Google-originated open-source projectsLinux Kernel Coding Style (or Documentation/CodingStyle in the Linux Kernel source tree)Mozilla Coding Style GuideRoad Intranet's C++ GuidelinesThe NetBSD source code style guide (formerly known as the BSD Kernel Normal Form)OpenBSD Kernel source file style guide (KNF)"GNAT Coding Style: A Guide for GNAT Developers". GCC online documentation. Free Software Foundation. Retrieved 2009-01-19. (PDF)ZeroMQ C Language Style for Scalability (CLASS)

以上是我了解到的有Coding conventions的项目,其中最早的也在2000年后,所以我觉得谈不上历史,只能说是一种程序员为了便于合作,制定出来的团队公约,目前还没有得到大范围的使用.

2.规格BUG分析

无

3.前置后置条件改进例子

错误:

1.使用了自然语言

2.错误使用了中间变量

3.格式错误

4.进行了同步控制却没有写相关的effects

5.使用了过多的常数,而非变量名

改进:

1.使用bool表达式

2.停止使用

3.学习正确的格式

4.先写完规格,再写方法

5.改为使用变量名

4.功能与规格BUG聚类分析

所有的功能bug均无对应的规格bug.

5.设计与撰写规格的一些体会

我感受到了设计规格带来的许多好处

一是通过设计规格,我发现了我设计能力的缺陷,经常写完规格,才发现写的不对,导致需要重新修改规格

二是通过设计规格,发现了码代码的能力的缺陷,等到修改完规格了之后,发现设计的规格,无法实现,或者在实现过程中发现了更好的方式,导致需要重新修改规格,以及代码.

三通过设计规格,发现了自己debug能力的缺陷,虽然只花了一天时间写规格,但是最后还是没时间debug了,再发现bug到修改过程中,发现修改后的代码与规格不同,导致要重新修改规格

四通过设计规格,我发现了我找bug能力的缺陷,通过通过观察规格与方法的设计,发现规格和方法相同,就觉得方法没有bug,最终发现是规格写的有bug,导致要重新修改规格.