• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            幽幽
             
            posts - 51,  comments - 28,  trackbacks - 0
            抨擊匈牙利命名法

            匈牙利命名法是一種編程時的命名規范。命名規范是程序書寫規范中最重要也是最富爭議的地方,自古乃兵家必爭之地。命名規范有何用?四個字:名正言順。用二分法,命名規范分為好的命名規范和壞的命名規范,也就是說名正言順的命名規范和名不正言不順的命名規范。好的舞鞋是讓舞者感覺不到其存在的舞鞋,壞的舞鞋是讓舞者帶著鐐銬起舞。一個壞的命名規范具有的破壞力比一個好的命名規范具有的創造力要大得多。

            本文要證明的是:匈牙利命名法是一個壞的命名規范。本文的作用范圍為靜態強類型編程語言。本文的分析范本為C語言和C++語言。下文中的匈法為匈牙利命名法的簡稱。

            一 匈牙利命名法的成本

            匈法的表現形式為給變量名附加上類型名前綴,例如:nFoo,szFoo,pFoo,cpFoo分別表示整型變量,字符串型變量,指針型變量和常指針型變量。可以看出,匈法將變量的類型信息從單一地點(聲明變量處)復制到了多個地點(使用變量處),這是冗余法。冗余法的成本之一是要維護副本的一致性。這個成本在編寫和維護代碼的過程中需要改變變量的類型時付出。冗余法的成本之二是占用了額外的空間。一個優秀的書寫者會自覺地遵從一個法則:代碼最小組織單位的長度以30個自然行以下為宜,如果超過50行就應該重新組織。一個變量的書寫空間會給這一法則添加不必要的難度。

            二 匈牙利命名法的收益

            這里要證明匈牙利命名法的收益是含糊的,無法預期的。

            范本1:strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)
            匈法在這里有什么收益呢?我看不到。沒有一個程序員會承認自己不知道strcpy函數的參數類型吧。

            范本2:unknown_function(nFoo) Vs unknown_function(foo)
            匈法在這里有什么收益呢?我看不到。對于一個不知道確定類型的函數,程序員應該去查看該函數的文檔,這是一種成本。使用匈法的唯一好處是看代碼的人知道這個函數要求一個整型參數,這又有什么用處呢?函數是一種接口,參數的類型僅僅是接口中的一小部分。諸如函數的功能、出口信息、線程安全性、異常安全性、參數合法性等重要信息還是必須查閱文檔。

            范本3:nFoo=nBar Vs foo=bar
            匈法在這里有什么收益呢?我看不到。使用匈法的唯一好處是看代碼的人知道這里發生了一個整型變量的復制動作,聽起來沒什么問題,可以安心睡大覺了。如果他看到的是nFoo=szBar,可能會從美夢中驚醒。且慢,事情真的會是這樣嗎?我想首先被驚醒的應該是編譯器。另一方面,nFoo=nBar只是在語法上合法而已,看代碼的人真正關心的是語義的合法性,匈法對此毫無幫助。另一方面,一個優秀的書寫者會自覺地遵從一個法則:代碼最小組織單位中的臨時變量以一兩個為宜,如果超過三個就應該重新組織。結合前述第一個法則,可以得出這樣的結論:易于理解的代碼本身就應該是易于理解的,這是代碼的內建高質量。好的命名規范對內建高質量的助益相當有限,而壞的命名規范對內建高質量的損害比人們想象的要大。

            三 匈牙利命名法的實施

            這里要證明匈牙利命名法在C語言是難以實施的,在C++語言中是無法實施的。從邏輯上講,對匈法的收益做出否定的結論以后,再來論證匈法的可行性,是畫蛇添足。不過有鑒于小馬哥曾讓已射殺之敵死灰復燃,我還是再踏上一支腳為妙。

            前面講過,匈法是類型系統的冗余,所以實施匈法的關鍵是我們是否能夠精確地對類型系統進行復制。這取決于類型系統的復雜性。

            先來看看C語言:

            1.內置類型:int,char,float,double 復制為 n,ch,f,d?好像沒有什么問題。不過誰來告訴我void應該怎么表示?
            2.組合類型:array,union,enum,struct 復制為 a,u,e,s?好象比較別扭。
            這里的難點不是為主類型取名,而是為副類型取名。an表示整型數組?sfoo,sbar表示結構foo,結構bar?ausfoo表示聯合結構foo數組?累不累啊。
            3.特殊類型:pointer。pointer在理論上應該是組合類型,但是在C語言中可以認為是內置類型,因為C語言并沒有非常嚴格地區分不同的指針類型。下面開始表演:pausfoo表示聯合結構foo數組指針?ppp表示指針的指針的指針?

            噩夢還沒有結束,再來看看類型系統更阿為豐富的C++語言:

            1.class:如果說C語言中的struct還可以用stru搪塞過去的話,不要夢想用cls來搪塞C++中的class。嚴格地講,class根本就并不是一個類型,而是創造類型的工具,在C++中,語言內置類型的數量和class創造的用戶自定義類型的數量相比完全可以忽略不計。stdvectorFoo表示標準庫向量類型變量Foo?瘋狂的念頭。
            2.命名空間:boostfilesystemiteratorFoo,表示boost空間filesystem子空間遍歷目錄類型變量Foo?程序員要崩潰了。
            3.模板:你記得std::map<std::string,std::string>類型的確切名字嗎?我是記不得了,好像超過255個字符,還是饒了我吧。
            4.模板參數:template <class T, class BinaryPredicate>const T& max(const T& a, const T& b, BinaryPredicate comp) 聰明的你,請用匈法為T命名。上帝在發笑。
            5.類型修飾:static,extern,mutable,register,volatile,const,short,long,unsigned 噩夢加上修飾是什么?還是噩夢。
            posted on 2008-05-02 02:26 幽幽 閱讀(2544) 評論(10)  編輯 收藏 引用 所屬分類: 雜集

            FeedBack:
            # re: 抨擊匈牙利命名法
            2008-05-02 08:22 | lovedday
            早就放棄匈牙利命名法了,匈牙利命名法可能在開發windows API的時候有用,那時的編譯器的變量和函數提示功能沒有那么強大,程序員可以從匈牙利命名法中得到好處。可是現在編譯器的信息提示功能已經非常強大,匈牙利命名法實際上是一種累贅,帶來的弊端遠遠超過它的好處,不利于代碼閱讀。  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2009-08-11 11:22 | 合體星人
            盡管樓主如此抨擊匈牙利命名法,那為什么不提出一個更有效的命名系統?  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2009-08-31 11:14 | 12311
            是這樣的,團隊開發時必須有一個命名規范,而自己制定一整套規范的話既麻煩又產生大量學習成本,新成員加入后首先要讓他適應新的規范,按照經驗看,改變一個程序員的命名規范是很花時間的,所以往往都是采用大家認知度較高的一種既存規范,所以首選仍然是匈牙利。
            另:沒有大型團隊合作項目經驗的人沒有資格對規范的東西提出抨擊~~~  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2009-11-09 19:30 | 曉宇
            我很是期待看到你用100個i做變量的表情.
            希望我不會碰到你寫的程序

            但是說實話,你很厲害,寫這么多.而且還找了例子,從這點來說 確實很厲害.  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2010-03-09 16:29 | koangel
            如果你們去維護過其他人的代碼,或參與過較大型產品的開發,就絕對不會這么說了,對于你們這種只會自己編碼的人,怎么可能理解的到其中的內涵?井底之蛙  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2010-04-23 13:04 | cvb
            @合體星人
            java程序員沒有聽說過所謂的命名法,但java程序的可讀性仍然是最強的。
            匈牙利命名法對VC程序有毀滅性的打擊  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2010-06-05 00:45 | 不想多說你了
            無知~~  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2010-08-10 20:36 | #
            對你無話可說,只能說你無知  回復  更多評論
              
            # re: 抨擊匈牙利命名法[未登錄]
            2012-04-10 13:42 | Alex
            慶幸樓主不是我同事
            更慶幸樓主不是我老大  回復  更多評論
              
            # re: 抨擊匈牙利命名法
            2013-03-15 10:56 | Linuxer
            Linus 本人說匈牙利命名法是brain damaged 很中肯!
              回復  更多評論
              

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(6)

            隨筆分類(35)

            隨筆檔案(51)

            文章分類(3)

            文章檔案(3)

            相冊

            我的鏈接

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久99精品久久久久久不卡| 久久精品成人国产午夜| 免费一级欧美大片久久网| 亚洲美日韩Av中文字幕无码久久久妻妇| 国产69精品久久久久99尤物| 亚洲国产成人精品女人久久久 | 久久综合伊人77777| 亚洲va国产va天堂va久久| 青草影院天堂男人久久| 伊人热热久久原色播放www| 国产精品久久久久久久| 久久精品综合网| 九九久久99综合一区二区| 性欧美大战久久久久久久 | 日韩欧美亚洲综合久久| 婷婷综合久久中文字幕| 亚洲欧美日韩中文久久| 久久天天婷婷五月俺也去| 国产AⅤ精品一区二区三区久久| 日日躁夜夜躁狠狠久久AV| 久久SE精品一区二区| 久久久WWW免费人成精品| 久久91亚洲人成电影网站| 一本一本久久aa综合精品| 性做久久久久久久久| 久久伊人色| 久久精品国产精品亚洲艾草网美妙| 久久久婷婷五月亚洲97号色| 精品国产乱码久久久久久人妻| 久久九九免费高清视频| 久久精品无码专区免费| 中文字幕亚洲综合久久2| 国产精品久久久久影院嫩草 | 亚洲中文久久精品无码ww16| 免费一级做a爰片久久毛片潮| 成人精品一区二区久久久| 69SEX久久精品国产麻豆| 丁香狠狠色婷婷久久综合| 狠狠色丁香久久婷婷综| 久久国产精品久久国产精品| 精品久久一区二区|