天天看點

算法第一章作業

作業1

本學期應該遵循的代碼規範(來自騰訊C++代碼規範)

4.1規則:程式塊要采用縮進風格編寫,縮進的空格數為4個。說明:

由開發工具自動生成的代碼可能不一緻,但如果開發工具可以配置,則應該統一配置縮進為4個空格

4.2規則:縮進或者對齊隻能使用空格鍵,不可使用TAB鍵。

使用TAB鍵需要設定

4.3規則:相對獨立的程式塊之間、變量說明之後必須加空行。說明:

以下情況應該是用空行分開:

1)函數之間應該用空行分開;

2)變量聲明應盡可能靠近第一次使用處,避免一次性聲明一組沒有馬上使用的變量;

3)用空行将代碼按照邏輯片斷劃分;

4)每個類聲明之後應該加入空格同其他代碼分開。

4)每個類聲明之後應該加入空格同其他代碼分開示例:

4.4規則:較長的語句(>80字元)要分成多行書寫。說明:

以下情況應分多行書寫:

1)長表達式要在低優先級操作符處劃分新行,操作符放在新行之首,劃分出的新行要進行适當的縮進,使排版整齊,語句可讀。

2)若函數或過程中的參數較長,則要進行适當的劃分。

3)循環、判斷等語句中若有較長的表達式或語句,則要進行适應的劃分,長表達式要在低優先級操作符處劃分新行,操作符放在新行之首

4.5規則:不允許把多個短語句寫在一行中

一行代碼隻做一件事情,如隻定義一個變量,或隻寫一條語句。這樣的代碼容易閱讀,并且友善于寫注釋。

4.6規則:if、for、do、while、case、switch、default等語句自占一行,且if、for、do、while等語句的執行語句部分無論多少都要加括号{}。

示例:

4.7規則:代碼行之内應該留有适當的空格說明:

采用這種松散方式編寫代碼的目的是使代碼更加清晰。代碼行内應該适當的使用空

格,具體如下:

1)關鍵字之後要留白格。像const、virtual、inline、case等關鍵字之後至少要留一個空格,否則無法辨析關鍵字 像if、for、while等關鍵字之後應留一個空格再跟左括号‘(’,以突出關鍵字。 

2)函數名之後不要留白格,緊跟左括号’(’,以與關鍵字差別。3)‘(’向後緊跟,‘ )’、‘,’、‘;’向前緊跟,緊跟處不留白格

4)‘,’之後要留白格, 如Function(x,y,z)。如果‘;’不是一行的結束符号,後也要留白格,

5)值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符,如“=”、“+=”“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<、“^”等二進制操作符的前後應當加空格。

6)一進制操作符如“!”、“~”、“++”、“–”、“&”(位址運算符)等前後不加空格。

7)像“[]”、“.”、“->” 這類操作符前後不加空格。

4.8建議:程式塊的分界符(如C/C++語言的大括号‘{’和‘}’)應各獨占一行并且位于同一列,同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程式都要采用如上的縮進方式。

5注釋

5.1規則:源檔案頭部應進行注釋,列出:生成日期、作者、子產品目的/功能等

5.2規則:函數頭部應進行注釋,列出:函數的目的/功能、輸入參數、輸出參數、傳回值等。示例:

下面這段函數的注釋比較标準,可以不局限于此格式,但上述資訊要包含在内。

5.3規則:注釋應該和代碼同時更新,不再有用的注釋要删除。5.4規則:注釋的内容要清楚、明了,不能有二義性。說明:錯誤的注釋不但無益反而有害。

5.5建議:避免在注釋中使用非常用的縮寫或者術語。

5.6建議:注釋的主要目的應該是解釋為什麼這麼做,而不是正在做什麼。如果從上下文不容易看出作者的目的,說明程式的可讀性本身存在比較大的問題,應考慮對其重構。5.7建議:避免非必要的注釋。

5.8規則:注釋的版式

說明:注釋也需要與代碼一樣整齊排版

1)注釋應與其描述的代碼相近,對代碼的注釋應放在其上方或右方(對單條語句的注釋)相鄰位置,不可放在下面,如放于上方則需與其上面的代碼用空行隔開。

2)注釋與所描述内容進行同樣的縮排。

3)将注釋與其上面的代碼用空行隔開。

4)變量、常量、宏的注釋應放在其上方相鄰位置或右方。示例:如下例子不符合規範。

5.9規則:對于所有有實體含義的變量、常量,如果其命名不是充分自注釋的,在聲明時都必須加以注釋,說明其實體含義。

5.10規則:資料結構聲明(包括數組、結構、類、枚舉等),如果其命名不是充分自注釋的,必須加以注釋。對資料結構的注釋應放在其上方相鄰位置,不可放在下面;對結構中的每個域的注釋可放在此域的右方。

5.11建議:對重要變量的定義需編寫注釋,特别是全局變量,更應有較詳細的注釋,包括對其功能、取值範圍、以及存取時注意事項等的說明。

5.12建議:分支語句(條件分支、循環語句等)需編寫注釋。說明:

這些語句往往是程式實作某一特定功能的關鍵,對于維護人員來說,良好的注釋幫助更好的了解程式,有時甚至優于看設計文檔。

5.13規則:注釋不宜過多,也不能太少,源程式中有效注釋量控制在20%~30%之間。 說明:

注釋是對代碼的“提示”,而不是文檔,不可喧賓奪主,注釋太多會讓人眼花缭亂。

6辨別符命名

6.1規則:命名盡量使用英文單詞,力求簡單清楚,避免使用引起誤解的詞彙和模糊的縮寫,使人産生誤解。

5.13規則:注釋不宜過多,也不能太少,源程式中有效注釋量控制在20%~30%之間。

說明:注釋是對代碼的“提示”,而不是文檔,不可喧賓奪主,注釋太多會讓人眼花缭亂

6.2規則:命名規範必須與所使用的系統風格保持一緻,并在同一項目中統一。說明

1)如在UNIX系統,可采用全小寫加下劃線的風格或大小寫混排的方式,但不能使用大小寫與下劃線混排的方式。

2)用作特殊辨別如辨別成員變量或全局變量的m_和g_,其後加上大小寫混排的方式是允許的。

6.3建議:變量的命名可參考“匈牙利”标記法(Hungarian Notation)

6.4規則:常量、宏和模闆名采用全大寫的方式,每個單詞間用下劃線分隔。

6.5建議:枚舉類型enum 常量應以大寫字母開頭或全部大寫。

6.6建議:命名中若使用了特殊約定或縮寫,則要有注釋說明。

6.7規則:自己特有的命名風格,要自始至終保持一緻,不可來回變化。

6.8規則:對于變量命名,禁止取單個字元(如i、j、k…),建議除了要有具體含義外,還能表明其變量類型、資料類型等,但i、j、k作局部循環變量是允許的。

2)避免使用看上去相似的名稱,如“l”、“1”和“I”看上去非常相似。

6.9建議:函數名以大寫字母開頭,采用謂-賓結構(動-名),且應反映函數執行什麼操作以及傳回什麼内容。說明:

函數在表達式中使用,通常用于if子句,是以它們的意圖應一目了然 示例:

不好的命名:if(CheckSize(x))

沒有幫助作用,因為它沒有告訴我們 CheckSize是在出錯時傳回true

還是在不出錯時傳回true

好的命名:if(ValidSize(x))

則使函數的意圖很明确

6.10建議:類、結構、聯合、枚舉的命名須分别以C、S、U、E開頭,其他部分遵從一般變量命名規範。

7可讀性

7.1規則:用括号明确表達式的操作順序,避免使用預設優先級。

7.2建議:不要編寫太複雜 、多用途的複合表達式。

7.3規則:涉及實體狀态或者含有實體意義的常量,避免直接使用數字,必須用有意義的枚舉或常量來代替。

7.4規則:禁止使用難以了解,容易産生歧義的語句。

8變量、結構

8.1建議:盡量少使用全局變量,盡量去掉沒必要的公共變量。說明:

公共變量是增大子產品間耦合的原因之一,故應減少沒必要的公共變量以降低子產品間的耦合度。

8.2規則:變量,特别是指針變量,被建立之後應當及時把它們初始化,以防止把未被初始化的變量當成右值使用。

說明:在C/C++中引用未經指派的指針,經常會引起系統崩潰。

8.3建議:仔細設計結構中元素的布局與排列順序,使結構容易了解、節省占用空間,并減少引起誤用現象。說明:

合理排列結構中元素順序,可節省空間并增加可了解性。

8.4建議:留心具體語言及編譯器處理不同資料類型的原則及有關細節。

8.5建議:盡量減少沒有必要的資料類型預設轉換與強制轉換。

8.6規則:當聲明用于分布式環境或不同CPU間通信環境的資料結構時,必須考慮機器的位元組順序、使用的位域及位元組對齊等問題。

9函數、過程

9.1規則:調用函數要檢查所有可能的傳回情況,不應該的傳回情況要用ASSERT來确認。

9.2建議:編寫可重入函數時,應注意局部變量的使用(如編寫C/C++語言的可重入函數時,應使用auto即預設态局部變量或寄存器變量)。說明:

編寫C/C++語言的可重入函數時,不應使用static局部變量,否則必須經過特殊處理,才能使函數具有可重入性。

9.3建議:調用公共接口函數時,調用者有保障調用參數符合要求的義務。作為一種防禦性的程式設計風格,被調用函數也應該對傳入參數做必要的安全檢查。

9.4建議:函數的規模盡量限制在100行以内。

說明:不包括注釋和空格行。

9.5建議:一個函數僅完成一件功能。說明:

多功能集于一身的函數,很可能使函數的了解、測試、維護等變得困難。

9.6建議:不能用ASSERT代替必要的安全處理代碼,確定釋出版的程式也能夠合理地處理異常情況。

函數的每種出錯傳回值的意義要清晰、明了、準确,防止使用者誤用、了解錯誤或忽視錯誤傳回碼。

10 C++專用規範

10.1規則:在高警告級别下幹淨地編譯。

使用編譯器的最高警告級别。要求幹淨的(沒有警告的)建構(build)并了解所有的警告。通過修改代碼來消除警告,而不是通過降低警告級别來消除。對于明确了解其含義,确信不會造成任何問題的警告,則可以局部關閉。

10.2規則:確定資源為對象所占有,使用顯式的RAII和智能指針。

C++在語言層面強制的構造/析構恰好與資源擷取/釋放這對函數相對應,在處理需要調用成對的擷取/釋放函數的資源時,應将該資源封裝在對象中,并在對象的析構函數中釋放該資源,這樣就保證了擷取/釋放的比對。

最好用智能指針來儲存動态配置設定的資源,而不要用原始指針。

10.3規則:主動使用const,避免使用宏。

三:個人編碼模闆

1 .1排版

1-1:程式塊要采用縮進風格編寫,縮進的空格數為4個。

1-2:相對獨立的程式塊之間、變量說明之後必須加空行。

1-3:較長的語句(>80字元)要分成多行書寫

1-4::不允許把多個短語句寫在一行中,即一行隻寫一條語句。 

1-5:if、for、do、while等語句的執行語句部分無論多少行都要加括号{}。

1-6:對齊隻使用空格鍵,不使用TAB鍵。

1-7:函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要采用縮進風格,case語句下的情況處理語句也要遵從語句縮進要求。

1-8:程式塊的分界符(如C/C++語言的大括号‘{’和‘}’)應各獨占一行并且位于同一列

1-9:循環、判斷等語句中若有較長的表達式或語句,則要進行适應的劃分,長表達式要在低優先級操作符處劃分新行,操作符放在新行之首。

1-10:在兩個以上的關鍵字、變量、常量進行對等操作時,它們之間的操作符之 前、之後或者前後要加空格;進行非對等操作時,如果是關系密切的立即操作符 (如->),後不應加空格。 采用這種松散方式編寫代碼的目的是使代碼更加清晰。

(1) 逗号、分号隻在後面加空格。

int a, b, c; 

(2)比較操作符, 指派操作符”=”、”+=”,算術操作符”+”、”%”,邏輯操

作符”&&”、”&”,位域操作符”<<”、”^”等雙目操作符的前後加空格。

a = b + c;

(3)”!”、”~”、”++”、”–”、”&”(位址運算符)等單目操作符前後不加

空格。

p = ‘a’;        // 内容操作”“與内容之間

flag = !isEmpty; // 非操作”!”與内容之間

p = &mem;        // 位址操作”&” 與内容之間

i++;             // “++”,”–”與内容之間

(4)”->”、”.”前後不加空格。

p->id = pid;     // “->”指針前後不加空格

(5) if、for、while、switch 等與後面的括号間應加空格,使if等關

鍵字更為突出、明顯。

if (a >= b && c > d)

(6)可以用括号來明确運算順序。

(7).符合指派運算符汝+=不能用空格空開。

1.2 注釋

2-1:一般情況下,源程式有效注釋量必須在20%以上。

2-2:檔案頭部應進行注釋,注釋必須列出:版權說明、版本号、生成日期、作者、内容、功能、修改日志等。

2-3:函數頭部應進行注釋,列出:函數的目的/功能、輸入參數、輸出參數、傳回值、調用關系(函數、表)等。

2-4:邊寫代碼邊注釋,修改代碼同時修改相應的注釋,以保證注釋與代碼的一緻性。不再有用的注釋要删除。

2-5:注釋的内容要清楚、明了,含義準确,防止注釋二義性。

2-6:注釋應與其描述的代碼相近,對代碼的注釋應放在其上方或右方(對單條語句的注釋)相鄰位置,不可放在下面,如放于上方則需與其上面的代碼用空行隔開。

2-7:變量、常量、宏的注釋應放在其上方相鄰位置或右方。

2-8:對資料結構的注釋應放在其上方相鄰位置,不可放在下面;對結構中的每個域的注釋放在此域的右方。

2-9:全局變量要有較詳細的注釋,包括對其功能、取值範圍、哪些函數或過程存取它以及存取時注意事項等的說明。

2-10:注釋與所描述内容進行同樣的縮排。

2-11:避免在一行代碼或表達式的中間插入注釋。

2-12:通過對函數或過程、變量、結構等正确的命名以及合理地組織代碼的結構,使代碼成為自注釋的。

2-13:注釋格式盡量統一,注釋格式用//

2-14:将注釋與其上面的代碼用空行隔開

2-15:對變量的定義和分支語句(條件分支、循環語句等)必須編寫注釋。

說明:這些語句往往是程式實作某一特定功能的關鍵,對于維護人員來說, 良好的注釋幫助更好的了解程式,有時甚至優于看設計文檔。

2-16:對于 switch 語句下的case 語句,如果因為特殊情況需要處理完一個 case 後進入下一個 case 處理,必須在該case 語句處理完、下一個 case 語句前加上明确的注釋。 有效防止無故遺漏 break 語句。

1.3 命名

3-1:辨別符的命名要清晰、明了,有明确含義,同時使用完整的單詞或大家基本可以了解的縮寫,避免使人産生誤解。

3-2:命名中若使用特殊約定或縮寫,則要有注釋說明。

3-3:對于變量命名,禁止取單個字元(如i、j、k…),建議除了要有具體含義外,還能表明其變量類型、資料類型等,但i、j、k 作局部循環變量是允許的。

3-4:不用數字或較奇怪的字元來定義辨別符。

3-5:用正确的反義詞組命名具有互斥意義的變量或相反動作的函數等。

3-6:自己特有的命名風格,要自始至終保持一緻,不可來回變化。

3-7.命名要用英文,可以出現英文、下劃線、數字。

3-8.檔案命名要用小寫字母,名字反映出檔案的内容,縮寫單詞要小寫,檔案名要用名詞不要用動詞。

3-9變量命名一律小寫,縮寫詞彙要大寫,要使用名詞,可以使用“”表示從屬關系。局部循環控制變量用 i,j,n,k,指針變量用p開頭,加上名詞。

3-10.數組命名首字母要大寫,其它同變量。

3-11.函數命名單詞首字母大寫,形式可以是“函數名_描述函數功能的動詞”,盡量寫出主謂格式。

3-12.使用typedef定義新類型,一個單詞首字母大寫。

3-13.宏命名全部大寫

1.4 函數、過程

4-1:對所調用函數的錯誤傳回碼要仔細、全面地處理。

4-2:明确函數功能,精确(而不是近似)地實作函數設計。

4-3:函數的規模盡量限制在200行以内。

4-4:一個函數僅完成一件功能,不要設計多用途面面俱到的函數。

說明:多功能集于一身的函數,很可能使函數的了解、測試、維護等變得困難。

4-5:函數的功能應該是可以預測的,也就是隻要輸入資料相同就應産生同樣的輸出。

4-6:檢查函數所有參數輸入的有效性。

4-8:檢查函數所有非參數輸入的有效性,如資料檔案、公共變量等。

4-9:函數名應準确描述函數的功能。

4-10:函數的傳回值要清楚、明了,讓使用者不容易忽視錯誤情況。

4-11:讓函數在調用點顯得易懂、容易了解。

4-12:在調用函數填寫參數時,應盡量減少沒有必要的預設資料類型轉換或強制資料類型轉換。

4-13:減少函數本身或函數間的遞歸調用。

4-14:改進子產品中函數的結構,降低函數間的耦合度,并提高函數的獨立性以及代碼可讀性、效率和可維護性。優化函數結構時,要遵守以下原則:

(1)不能影響子產品功能的實作。

(2)仔細考查子產品或函數出錯處理及子產品的性能要求并進行完善。

(3)通過分解或合并函數來改進軟體結構。

(4)考查函數的規模,過大的要進行分解。

(5)降低函數間接口的複雜度。

(6)不同層次的函數調用要有較合理的扇入、扇出。

(7)函數功能應可預測。

4-15:避免使用BOOL參數。

4-16:對于提供了傳回值的函數,在引用時最好使用其傳回值。

1.5 宏

5-1:用宏定義表達式時,要使用完備的括号。

5-2:将宏所定義的多條表達式放在大括号中。

 作業2

《數學之美》第七章(賈裡尼克和現代語言處理)讀後感

  這一章介紹了賈裡尼克的一生,在我看來,他的童年與青年時代是幸福與不幸交織在一起的,不幸在于他總是被迫改變夢想,幸福在于他能夠在童年養成的好的學習觀念為他之後的成功奠定了基礎。在成年之後,他組建了自己的實驗室并在自己的不懈努力下使自然語言識别達到了新的高度,取得如此偉大的成績。在晚年,他依舊靠着自己的努力堅持在工作崗位上,隻不過是從實驗室來到了世界一流研究中心,直到生命的最後一刻,他仍舊在工作崗位上。

繼續閱讀