軟件工程理論與實踐課件：第7章 程序的編寫

1、chapter 7,Writing the Programs程序的編寫,SOFTWARE ENGINEERING,chapter 7,7.1Programming standards and procedures編程標準和過程,Reasons:Others are able to understand what you have written, why you have written it and how it fits in with their work. 讓別人理解你寫了什么，為什么寫以及它同工作是如何配合的。,chapter 7,Software engineering stand

2、ards 軟件工程標準,Standards for you 個人的標準 Help you to organize your thoughts and avoid mistakes. Standardized documentation helps in locating faults and making changes, because it clarifies which sections of your program perform which functions.幫你組織思想，避免錯誤 。標準化的文檔還有助于查找錯誤的位置并作出改動。 Help in translating desi

3、gns to code. By structuring code according to standards, you maintain the correspondence between design components and code components. 有助 于你將設計轉化成代碼，維持設計組件何代碼組件之間的一 致性。,chapter 7,Standards for others 其他人的標準 You organize, format, and document your code to make it easy for other to understand what it

4、 does and how it works. 組織、排版及編寫代碼文檔，使其他人容 易理解軟件做什么及如何運行。,chapter 7,Matching design with implementation設計與實現的匹配 The most critical standard is the need for a direct correspondence between the program design components and the program code components.最關鍵的標準就是需要在程序設計組件和程序代碼組件之間有直接的對應關系. (系統(tǒng)的一般目的是在整個軟件生

5、命周期中保持一致,設計和代碼之間的一致性是基本問題.),chapter 7,Standard format for comments注釋的標準格式,/* Statement of function: 函數功能 * Component name: 組件名 * Programmer: 程序員 * Version: 版本 * Procedure Invocation: 過程調用 * Input Parameters: 輸入參數 * Output Parameters: 輸出參數 */,chapter 7,7.2 Programming Guidelines 編程指導方針,Major aspects

6、of programming編程的主要方面： control structures 控制結構 Algorithms 算法 data structures 數據結構,chapter 7,Control structures 控制結構,Many of control structures for a component are suggested by the architecture and design. It is important for your program structure to reflect the designs control structure.體系結構和設計提出了很

7、多組件的控制結構，程序結構反映設計的控制結構是非常重要的。 Many guidelines and standards suggest that the code be written so you can read a component easily from the top down.許多指導方針和標準建議代碼應寫成便于從上至下閱讀一個組件的樣式。,chapter 7,Example:,chapter 7,結構程序設計的概念最早由E.W.Dijkstra在1965年提出，他指出：“可以從高級語言中取消GOTO語句”，“程序的質量與程序中所包含的GOTO語句的數量成反比”。 1966年Bo

8、hm和Jacopini證明了，只用3種基本的控制結構就能實現任何單入口單出口的程序。這3種基本的控制結構是“順序”、“選擇”和“循環(huán)”。 1968年Dijkstra再次建議，1971年IBM成功地應用結構程序設計在紐約時報信息庫管理系統(tǒng)和美國宇航局飛行模擬實驗中。,結構程序設計,chapter 7,結構程序設計,結構程序設計的經典定義如下所述：“如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結構進行連接，并且每個代碼塊只有一個入口和一個出口，則稱這個程序是結構化的?！?對經典定義的擴充：“結構程序設計是盡可能少用GOTO語句的程序設計方法。最好僅在檢測出錯誤時才使用GOTO語句，而

9、且應該總是使用前向GOTO語句。”,chapter 7,結構程序設計,經典的結構程序設計：如果只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環(huán)這3種基本控制結構實現單入口單出口的程序 擴展的結構程序設計：如果除了上述3種基本控制結構之外，還允許使用DO-CASE型多分支結構和DO-UNTIL型循環(huán)結構 修正的結構程序設計：如果再加上允許使用LEAVE(或BREAK)結構,chapter 7,結構程序設計,chapter 7,結構程序設計,chapter 7,Control structure 控制結構,Generality is a virtue，do not make

10、your code more specialized than it needs to be. Dont make your components so general that performance and understanding are affected. 一般性是優(yōu)點，不要讓你的代碼太特殊。不要讓組件過分全面，從而影響性能和理解。,chapter 7,Algorithms算法,Efficiency may have hidden costs cost to write the code faster cost to test the code cost to understand

11、the code cost to modify the code,“Index = 3*i + 2 *j +k” better or worse?,chapter 7,Data structure,Keeping the program simple 保持程序簡單易懂 Using a data structure to determine a program structure. 用數據結構確定程序結構 For example, recursive. P315.,chapter 7,Keep the program simple (1),chapter 7,Keep the program s

12、imple (2),chapter 7,General guidelines 一般指導原則,Localize input and output使輸入輸出局部化 Including pseudocode包括偽代碼 Revise and rewrite, rather than patch修改與重寫，勝于打補丁 Reuse 復用 Producer reuse 生產者復用 Consumer reuse 消費者復用,chapter 7,Consumer reuse消費者復用 Does the component perform the function or provide the data you

13、need?組件是否能執(zhí)行所需功能或者提供所需數據？ If minor modification is required, is it less modification than building the component from scratch?如果要進行小的改動，改動工作是否比重新構造組件的工作要少？ Is the component well-documented, so you can understand it without having to verify its implementation line by line?組件的文檔是否完整，這樣不用逐行閱讀代碼就能理解該組件？

14、 Is there a complete record of the components test and revision history, so you can be certain that it contains no faults?是否有完整的組件測試和修改歷史的記錄，這樣你就能確信它不包含任何錯誤？,chapter 7,Producer reuse生產者復用 Make your component general, using parameters and anticipating similar conditions to the ones in which your syst

15、em will invoke your components.讓組件比較通用，使用類似于將要調用該組件的系統(tǒng)中的參數和期望的類似條件。 Separate dependencies so sections likely to need change are isolated from those that are likely to remain the same.將可能改變的部分和保持不變的部分的依賴關系分開。 Keep the component interface general and well-defined.保證組件的接口全面而定義明確。 Include information ab

16、out any faults found and fixed.使用清楚的命令規(guī)范。 Use clear naming conventions.記錄數據結構和算法。 Keep the communication and error-handing sections separate and easy to modify.保持通信和錯誤處理部分的獨立性，而且要易于修改。,chapter 7,7.3Documentation文檔,We consider program documentation to be the set of written descriptions that explain t

17、o a reader what the programs do and how they do it. Internal documentation is descriptive material written directly within the code; all other documentation is external documentation. 程序文檔是向讀者解釋程序做什么以及如何實現的書面描述。內部文檔是直接寫在代碼中的描述材料，所有其他的文檔都是外部文檔。,chapter 7,Internal documentation header comment block ot

18、her program comments meaningful variable names and statement labels format to enhance understanding document data External documentation describe the problem describe the algorithm describe the data,chapter 7,編碼風格：程序的內部文檔,好程序的代碼邏輯簡明清晰、易讀易懂： 程序的內部文檔 數據說明 語句構造 輸入輸出方法 效率問題,chapter 7,編碼風格：程序的內部文檔,標識符的命名

19、： 標識符即符號名，包括模塊名、變量名、常量名、標號名、子程序名、數據區(qū)名以及緩沖區(qū)名等。 這些名字應能反映它所代表的實際東西，應有一定實際意義。(例如，表示次數的量用Times，表示總量的用Total，表示平均值的用Average，表示和的量用Sum等。) 名字不是越長越好，應當選擇精煉的意義明確的名字。 必要時可使用縮寫名字，但這時要注意縮寫規(guī)則要一致，并且要給每一個名字加注釋。 在一個程序中，一個變量只應用于一種用途。,chapter 7,編碼風格：程序的內部文檔,程序的注解： 夾在程序中的注釋是程序員與日后的程序讀者之間通信的重要手段。 注釋決不是可有可無的。 一些正規(guī)的程序文本中，注

20、釋行的數量占到整個源程序的13到12，甚至更多。 注釋分為序言性注釋和功能性注釋。,chapter 7,編碼風格：程序的內部文檔,序言性注釋： 通常置于每個程序模塊的開頭部分，它應當給出程序的整體說明，對于理解程序本身具有引導作用。有些軟件開發(fā)部門對序言性注釋做了明確而嚴格的規(guī)定，要求程序編制者逐項列出。 有關項目包括： 程序標題； 有關本模塊功能和目的的說明； 主要算法； 接口說明：包括調用形式，參數描述，子程序清單； 有關數據描述：重要的變量及其用途，約束或限制條件，以及其它有關信息； 模塊位置：在哪一個源文件中，或隸屬于哪一個軟件包； 開發(fā)簡歷：模塊設計者，復審者，復審日期，修改日期及有

21、關說明等。,chapter 7,編碼風格：程序的內部文檔,功能性注釋： 功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執(zhí)行了下面的語句會怎么樣。而不要解釋下面怎么做。,chapter 7,編碼風格：程序的內部文檔,視覺組織： 空格、空行和縮進。 恰當地利用空格，可以突出運算的優(yōu)先性。 自然的程序段之間可用空行隔開。 縮進也叫做向右縮格或移行。它是指程序中的各行不必都在左端對齊，都從第一格起排列。這樣做使程序完全分不清層次關系。 對于選擇語句和循環(huán)語句，把其中的程序段語句向右做階梯式移行。使程序的邏輯結構更加清晰。,chapter 7,編碼風格：數據說明,在設計階段已經

22、確定了數據結構的組織及其復雜性。在編寫程序時，則需要注意數據說明的風格。 為了使程序中數據說明更易于理解和維護，必須注意以下幾點： 數據說明的次序應當規(guī)范化； 說明語句中變量安排有序化； 使用注釋說明復雜數據結構。,chapter 7,編碼風格：數據說明,數據說明的次序應當規(guī)范化： 數據說明次序規(guī)范化，使數據屬性容易查找，也有利于測試，排錯和維護。 原則上，數據說明的次序與語法無關，其次序是任意的。但出于閱讀、理解和維護的需要，最好使其規(guī)范化，使說明的先后次序固定。 例如，在類型說明中可按如下順序排列： 整型量說明 實型量說明 字符量說明 邏輯量說明,chapter 7,編碼風格：數據說明,說

23、明語句中變量安排有序化： 當多個變量名在一個說明語句中說明時，應當對這些變量按字母的順序排列。 例如，把 integer size, length, width, cost, price寫成integer cost, length, price , size, width,chapter 7,編碼風格：數據說明,使用注釋說明復雜數據結構： 如果設計了一個復雜的數據結構，應當使用注釋來說明在程序實現時這個數據結構的特點。 例如, 對C的鏈表結構和Pascal中用戶自定義的數據類型，都應當在注釋中做必要的補充說明。,chapter 7,編碼風格：語句構造,在設計階段確定了軟件的邏輯流結構，但構造單

24、個語句則是編碼階段的任務。語句構造力求簡單、直接，不能為了片面追求效率而使語句復雜化。 下面是關于語句構造的一些啟發(fā)規(guī)則：,chapter 7,編碼風格：語句構造,1. 在一行內只寫一條語句。 2.避免采用過于復雜的條件測試。 3.盡量減少 “非”條件的測試。 IF NOT (CHAR9) THEN IF (CHAR=0) AND (CHAR=9) THEN 4.避免大量使用循環(huán)嵌套和條件嵌套。 5.利用括號使邏輯表達式或算術表達式的運算次序清晰直觀。,chapter 7,編碼風格：語句構造,6.除非對效率有特殊的要求，程序編寫要做到清晰第一，效率第二。不要為了追求效率而喪失了清晰性。事實上，

25、程序效率的提高主要應通過選擇高效的算法來實現。 對比下面兩個程序段，哪個更清楚表達了自己的意圖？,A I =A I A T ；A T =A I A T ；A I =A I A T ；,WORK = A T ；A T = A I ；A I = WORK；,chapter 7,編碼風格：語句構造,7.程序要能直截了當地說明程序員的用意。對比下面兩個程序段，哪個更直接地表達了自己的意圖？,for ( i = 1; i = n; i+ ) for ( j = 1; j = n; j+ ) Vij = ( ij ) * ( ji ),for ( i1; i = n; i+ ) for ( j1; j =

26、 n; j+ ) if ( i = j ) Vij = 1; else Vij = 0;,chapter 7,編碼風格：語句構造,8.首先要保證程序正確, 然后才要求提高速度。反過來說，在使程序高速運行時，首先要保證它是正確的。 9. 讓編譯程序做簡單的優(yōu)化。 10. 盡可能使用庫函數。 11.避免使用臨時變量而使可讀性下降。例如，有的程序員為了追求效率， 將 X=A I + 1/A I 寫成 AI=AI; X=AI+1/AI，將一個計算公式拆成了幾行。 12. 避免不必要的轉移。同時如果能保持程序可讀性，則不必用 GOTO語句。,chapter 7,編碼風格：語句構造,13.盡量只采用三種基

27、本的控制結構來編寫程序。 14. 避免使用空的ELSE語句和IF THEN IF的語句。這種結構容 易使讀者產生誤解。例如： IF (CHAR=A) THEN IF (CHAR=Z) THEN PRINT “This is a letter.” ELSE PRINT “This is not a letter.” 15. 不要單獨進行浮點數的比較，而是采用|x0-x1|e 16. 盡可能用通俗易懂的偽碼來描述程序的流程，然后再翻譯成必須使用的語言。,chapter 7,編碼風格：語句構造,對于語句構造，可以列舉出很多實踐總結出來的經驗規(guī)則。但是再多的規(guī)則都不如經常反躬自?。?“如果我不是編碼的

28、人，那么能看懂它嗎？”,chapter 7,編碼風格：輸入輸出,關于輸入和輸出有下列的啟發(fā)規(guī)則： 1.對所有的輸入數據都要進行檢驗，識別錯誤的輸入，以保證每個數據的有效性； 2.檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態(tài)信息； 3.使得輸入的步驟和操作盡可能簡單，并保持簡單的輸入格式； 4.輸入數據時，應允許使用自由格式輸入； 5.應允許缺省值； 6.輸入一批數據時，最好使用輸入結束標志，而不要由用戶指定輸入數據數目；,chapter 7,編碼風格：輸入輸出,7.在交互式輸入輸出時，要在屏幕上使用提示符 明確提示交互輸入的請求，指明可使用選擇項的種類和取值范圍。同時，在數據輸入的過程

29、中和輸入結束時，也要在屏幕上給出狀態(tài)信息； 8.當程序設計語言對輸入輸出格式有嚴格要求時，應保持輸入格式與輸入語句要求的一致性； 9.給所有的輸出加注解，并設計輸出報表格式。輸入輸出風格還受到許多其它因素的影響。如輸入輸出設備（例如終端的類型，圖形設備，數字化轉換設備等）、用戶的熟練程度、以及通信環(huán)境等。,chapter 7,編碼風格：效率問題,效率是性能要求，因此應該在需求分析階段確定效率方面的要求。 效率是靠好設計來提高的。 程序的效率和程序的簡單程度是一致的，不要犧牲程序的清晰性和可讀性來不必要地提高效率。,chapter 7,編碼風格：效率問題,程序運行時間：源程序的效率直接由詳細設計

30、階段確定的算法的效率決定，但是，寫程序的風格也能對程序的執(zhí)行速度和存儲器要求產生影響。 寫程序之前先簡化算術的和邏輯的表達式； 仔細研究嵌套的循環(huán)，以確定是否有語句可以從內層往外移； 盡量避免使用多維數組； 盡量避免使用指針和復雜的表； 使用執(zhí)行時間短的算術運算； 不要混合使用不同的數據類型； 盡量使用整數運算和布爾表達式。,chapter 7,過程設計技術和工具,表達過程規(guī)格說明的工具叫做詳細設計工具： 圖形工具 表格工具 語言工具,chapter 7,過程設計技術和工具,程序流程圖（Program Flow Chart） 程序流程圖本質上不是逐步求精的好工具，它誘使程序員過早地考慮程序的控

31、制流程，而不去考慮程序的全局結構。 程序流程圖中用箭頭代表控制流，因此程序員不受任何約束，可以完全不顧結構程序設計的精神，隨意轉移控制。 程序流程圖不易表示數據結構。,chapter 7,過程設計技術和工具,必須限制程序流程圖只能使用五種基本的控制結構 需要對流程圖所用的符號做出確切的規(guī)定,chapter 7,chapter 7,過程設計技術和工具,盒圖（Box-Diagram）（N-S圖） Nassi和Shneiderman提出,chapter 7,示例,chapter 7,N-S圖的嵌套定義形式,chapter 7,過程設計技術和工具,盒圖有下述特點： 功能域(即某個特定控制結構的作用域)

32、明確，可以從盒圖上一眼就看出來。 不可能任意轉移控制。 很容易確定局部和全程數據的作用域。 很容易表現嵌套關系，也可以表示模塊的層次結構。,chapter 7,過程設計技術和工具,PAD（Problem Analysis Diagram）圖：1973年由日本日立公司發(fā)明 用二維樹形結構的圖來表示程序的控制流, 設置了五種基本控制結構的圖式，并允許遞歸使用。,chapter 7,PAD描述的示例,chapter 7,PAD的擴充控制結構,chapter 7,PAD圖的主要優(yōu)點: 使用表示結構化控制結構的PAD符號所設計出來的程序必然是結構化程序 PAD圖所描繪的程序結構十分清晰 用PAD圖表現程

33、序邏輯，易讀、易懂、易記 容易將PAD圖轉換成高級語言源程序，這種轉換可用軟件工具自動完成 即可用于表示程序邏輯，也可用于描繪數據結構 PAD圖的符號支持自頂向下、逐步求精方法的使用,過程設計技術和工具,chapter 7,畫出下列程序流程圖對應的PAD圖,chapter 7,chapter 7,過程設計技術和工具,判定表 當算法中包含多重嵌套的條件選擇時，使用判定表能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。 判定表用于表示程序的靜態(tài)邏輯。 在判定表中的條件部分給出所有的兩分支判斷的列表，動作部分給出相應的處理。 要求將程序流程圖中的多分支判斷都改成兩分支判斷。,chapter

34、7,無多分支判斷結構,chapter 7,chapter 7,過程設計技術和工具,判定表 優(yōu)點：能夠簡潔、無二義性地描述所有的處理規(guī)則。 缺點：判定表表示的是靜態(tài)邏輯，是在某種條件取值組合情況下可能的結果，它不能表達加工的順序，也不能表達循環(huán)結構，因此判定表不能成為一種通用的設計工具。,chapter 7,過程設計技術和工具,判定樹 判定樹是判定表的變種。 優(yōu)點：形式簡單，比判定表更直觀 缺點： 簡潔性不如判定表 畫判定樹時分枝的次序可能對最終畫出的判定樹的簡潔程度有較大影響,chapter 7,過程設計技術和工具,過程設計語言（PDL） 是用正文形式表示數據和處理過程的設計工具，也被稱為偽代

35、碼。 PDL具有嚴格的關鍵字外部語法，用于定義控制結構和數據結構；另一方面，PDL表示實際操作和條件的內部語法通常又是靈活自由的，可以適應各種工程項目的需要。,chapter 7,過程設計技術和工具,PROCEDURE spellcheck IS 查找錯拼的單詞 BEGIN split document into single words 把整個文檔分離成單詞 look up words in dictionary 在字典中查這些單詞 display words which are not in dictionary 顯示字典中查不到的單詞 create a new dictionary 造一

36、新字典 END spellcheck,示例: 拼寫檢查程序,chapter 7,過程設計技術和工具,PDL作為一種設計工具有如下一些優(yōu)點： 可以作為注釋直接插在源程序中間。這樣做能促使維護人員在修改程序代碼的同時也相應地修改PDL注釋，因此有助于保持文檔和程序的一致性，提高了文檔的質量 可以使用普通的正文編輯程序或文字處理系統(tǒng)，很方便地完成PDL的書寫和編輯工作。 已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。 PDL的缺點是不如圖形工具形象直觀，描述復雜的條件組合與動作間的對應關系時，不如判定表清晰簡單。,chapter 7,程序復雜程度的定量度量,定量度量程序復雜程度的方法的用

37、途： 把程序的復雜程度乘以適當常數即可估算出軟件中錯誤的數量以及軟件開發(fā)需要用的工作量； 定量度量的結果可以用來比較兩個不同的設計或兩個不同算法的優(yōu)劣； 程序的定量的復雜程度可以作為模塊規(guī)模的精確限度。,chapter 7,McCabe方法,McCabe方法根據程序控制流的復雜程度定量度量程序的復雜程度，這樣度量出的結果稱為程序的環(huán)形復雜度。 流圖（也稱為程序圖）：實質上是“退化了的”程序流程圖，它僅僅描繪程序的控制流程，完全不表現對數據的具體操作以及分支或循環(huán)的具體條件。 結點：用圓表示，代表一條或多條語句； 邊：用箭頭表示，一邊必須終止于一個結點； 區(qū)域：由邊和結點圍成的面積 ；,chap

38、ter 7,McCabe方法,流程圖、流圖以及E、N、V的對應關系：,順序型,選擇型,chapter 7,McCabe方法,流程圖、流圖以及E、N、V的對應關系：,WHILE 循環(huán),UNTIL 循環(huán),chapter 7,McCabe方法,流程圖、流圖以及E、N、V的對應關系：,示例,chapter 7,McCabe方法,把程序流程圖映射成流圖,chapter 7,PDL Procedure:sort 1：do while records remain 2 : read record； if record field 1=0 3 : then process record; store in b

39、uffer; incremert counter; 4 : elseif record field 2=0 5 : then reset counter; 6 : else process record; store in file; 7a : endif endif 7b : enddo 8 : end,圖6.16 由PDL翻譯成的流圖,chapter 7,包含復合條件的PDL映射成的流圖,chapter 7,McCabe方法,有了描繪程序控制流的流圖之后，可以用下述3種方法中的任何一種來計算環(huán)形復雜度。 流圖中的區(qū)域數等于環(huán)形復雜度。 流圖G的環(huán)形復雜度V(G)EN+2，其中，E是流圖中邊

40、的條數，N是結點數。 流圖G的環(huán)形復雜度V(G)P+1，其中，P是流圖中判斷的數目。,chapter 7,McCabe方法,環(huán)形復雜度的用途 程序的環(huán)形復雜度取決于程序控制流的復雜程度，也即是取決于程序結構的復雜程度。 當程序內分支數或循環(huán)個數增加時，環(huán)形復雜度也隨之增加，因此它是對測試難度的一種定量度量，也能對軟件最終的可靠性給出某種預測。 用來限制模塊的最大行數。McCabe從大量的調查中發(fā)現，當V(G)等于或大于10時，對模塊進行充分的測試將變得非常困難。他主張將10作為環(huán)域數的上限，并以此來限制模塊的最大規(guī)模,chapter 7,McCabe方法,幾點說明： 環(huán)形復雜度取決于程序控制結

41、構的復雜度。當程序的分支數目或循環(huán)數目增加時其復雜度也增加。環(huán)形復雜度與程序中覆蓋的路徑條數有關。 環(huán)形復雜度是可加的。例如，模塊A的復雜度為3，模塊B的復雜度為4，則模塊A與模塊B的復雜度是7。 McCabe建議，對于復雜度超過10的程序，應分成幾個小程序，以減少程序中的錯誤。Walsh用實例證實了這個建議的正確性。在McCabe復雜度為10的附近，存在出錯率的間斷躍變。,chapter 7,McCabe方法,這種度量的缺點： 對于不同種類的控制流的復雜性不能區(qū)分； 簡單IF語句與循環(huán)語句的復雜性同等看待； 嵌套IF語句與簡單CASE語句的復雜性是一樣的； 模塊間接口當成一個簡單分支一樣處理

42、； 一個具有1000行的順序程序與一行語句的復雜性相同；,chapter 7,畫出下列程序流程圖對應的程序圖,chapter 7,Halstead方法,它根據程序中運算符和操作數的總數來度量程序的復雜程度。,運算符包括： 算術運算符 賦值符（= 或 := ） 數組操作符 邏輯運算符 分界符（，或 ；或 : ） 子程序調用符 關系運算符 括號運算符循環(huán)操作符等 特別地，成對的運算符，例如“BEGINEND”、 “FORTO”、“REPEAT UNTIL”、“WHILEDO”、 “IFTHENELSE”、“（）”等都當做單一運算符。,運算對象包括變量名和常數,chapter 7,Halstead方法, 程序長度，即預測的Halstead長度 n1表示程序中不同運算符（包括保留字）的個數， n2表示程序中不同運算對象的個數， H表示“程序長度”，則有 H = n1log2n1+ n2log2n2,chapter 7,Halstead方法, 實際的Halstead長度 設