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,致使要從新修改規格.