• <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>

            love in C++, live on MFC

            to get ready...

            C++博客 首頁 新隨筆 聯(lián)系 聚合 管理
              47 Posts :: 0 Stories :: 97 Comments :: 0 Trackbacks

            書上說匈牙利命名法已經(jīng)過時(shí)了,我不這樣認(rèn)為。

            有人認(rèn)為現(xiàn)在編譯器已經(jīng)可以很好的檢測出類型的不匹配,或者IDE中可以很快的看到類型,所以在c中可能需要,在C++(強(qiáng)類型語言)中就不需要了。
            C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors.? So, I agree with the previous poster that it's now redundant.
            Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.


            不過我覺得代碼不是寫給編譯器看的,而是寫給人看的,這里就有self-documenting和readability的問題。
            很明顯,如果你看到nIndex 或者strFile或者wndNext,就可以很快知道分別是int CString CWnd類型,而不用回頭去看變量定義,這樣,看代碼時(shí)就會(huì)很快。
            而且,對于MFC程序員來說,更重要一些,因?yàn)镸FC里面的變量都是用匈牙利命名法的。
            If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
            微軟的約定,就是標(biāo)準(zhǔn)了

            不過,書上提到在泛型編程中不需要,現(xiàn)在體會(huì)還不深,可能是對的。

            今天(2006 04 13碰巧看到codeproject的一個(gè)vote),結(jié)果如下

            Option Votes %
            Pascal Cased 171 10.6
            camel Cased 702 43.4
            Fixed letter prefix (eg lLocal) 81 5.0
            Hungarian prefix (eg strLocal) 481 29.7
            Scope prefix (eg l_Local) 36 2.2
            Scope and Hungarian prefix (eg l_strLocal) 125 7.7
            Responses 1618 ?

            Hungarian Notation排第二.
            cp上面有兩個(gè)鏈接
            Conversations: Hungarian wartHogs (http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
            號稱這篇文章就已經(jīng)明白的說HN過時(shí)了(作者也是c++ coding stardard的作者).
            如果不用HN,那么應(yīng)該用什么樣的命名規(guī)則呢?
            Naming Guidelines(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNamingGuidelines.asp)
            .Net下的推薦,也許別的地方也可以用.
            posted on 2006-04-05 19:45 flyingxu 閱讀(616) 評論(5)  編輯 收藏 引用 所屬分類: C++ Coding Standards

            Feedback

            # re: Is Hungarian notation obsolete? 2006-04-07 10:20 小明
            對于變量命名,我的原則就是入鄉(xiāng)隨俗

            寫MFC程序就用匈牙利
            寫Java程序就用Java命名
            寫Linux程序大部分都用小寫和下劃線
            改別人的程序就按別人的標(biāo)準(zhǔn)

            總之,目標(biāo)是使代碼看起來是一個(gè)人寫的。  回復(fù)  更多評論
              

            # re: Is Hungarian notation obsolete? 2006-04-11 16:11 ace
            編碼規(guī)范要看你是站在哪層面上來看.
            如果全是VC+MFC,那用Hungarian style的就足夠了.

            但是,我以前也是Hungarian的"支持"者,但后來發(fā)現(xiàn)它有太多的與編碼規(guī)范其它條款抵觸的地方.現(xiàn)在我也不支持它了.

            清晰、可理解的 C++ 源代碼是規(guī)則和指南的主要目標(biāo):清晰、可理解的源代碼是軟件可靠性和可維護(hù)性的主要作用因素.
            清晰、可理解的代碼可以表示為以下三個(gè)簡單的基礎(chǔ)原理
            最小混淆 - 它的生存期中,源代碼的讀遠(yuǎn)比寫多,規(guī)約更是這樣。理想情況下,源代碼讀起來應(yīng)該象英語一樣描述了所要做的事,這同時(shí)還帶來了它執(zhí)行的好處。程序更多是為人編寫,而不是為計(jì)算機(jī)而編寫。閱讀代碼是一個(gè)復(fù)雜的腦力過程,它可由統(tǒng)一標(biāo)準(zhǔn)來簡化,在本文中還指最小混淆原則。整個(gè)項(xiàng)目中統(tǒng)一樣式是軟件開發(fā)團(tuán)隊(duì)在編程標(biāo)準(zhǔn)上達(dá)成一致的主要原因,它不應(yīng)視為一種懲罰或?qū)?chuàng)造性和生產(chǎn)力的阻礙。
            維護(hù)的唯一點(diǎn) - 只要可能,設(shè)計(jì)決策就應(yīng)在源中只表述一點(diǎn),它的多數(shù)后果應(yīng)程序化的派生于此點(diǎn)。不遵守這一原則嚴(yán)重?fù)p害了可維護(hù)性、可靠性和可理解性。
            最小干擾 - 最終,應(yīng)用最小干擾原則(它是易讀性的主要作用因素)。即,避免將源代碼與可視干擾(如內(nèi)容較少或?qū)斫廛浖康牟黄鹱饔玫男畔ⅲ┫嗷旌希?

            去年得了jolt大獎(jiǎng)的 C++ Coding Standards 一書
            http://www.huachu.com.cn/2006/c++.htm

            也把Hungarian 樣式的風(fēng)格作了批評.


              回復(fù)  更多評論
              

            # re: Is Hungarian notation obsolete? 2006-04-13 16:20 flyingxu
            @ace
            很感興趣你回復(fù)中的觀點(diǎn),能有具體例子說明一下嗎?

            估計(jì)HN真的正在慢慢的過時(shí),在codeproject中的一個(gè)vote中,HN排第二.
            http://www.codeproject.com/script/survey/detail.asp?survey=554
              回復(fù)  更多評論
              

            # re: Is Hungarian notation obsolete? 2006-04-14 09:57 Stone Jiang
            @flyingxu
            有空多交流這個(gè)話題,我要整理之后才能給出一個(gè)自已覺得滿意點(diǎn)的回復(fù).
            晚些時(shí)候再來個(gè)詳細(xì)的.   回復(fù)  更多評論
              

            # re: Is Hungarian notation obsolete? 2006-05-12 09:13 ztwaker
            我贊成小明的意見。  回復(fù)  更多評論
              

            欧美伊人久久大香线蕉综合| 无码久久精品国产亚洲Av影片 | 青青草国产成人久久91网| 99久久精品免费看国产| 99蜜桃臀久久久欧美精品网站| 久久国产精品99精品国产987| 精品伊人久久久| 久久综合狠狠综合久久| 久久久亚洲裙底偷窥综合| 久久精品国产精品亚洲下载 | 国内精品伊人久久久久影院对白| 波多野结衣AV无码久久一区| 久久99精品国产一区二区三区| 久久精品国产国产精品四凭| 99久久人妻无码精品系列| 精品伊人久久大线蕉色首页| 久久中文字幕一区二区| 99久久99久久精品国产片果冻| 日韩精品国产自在久久现线拍 | 久久久久亚洲AV综合波多野结衣 | 久久男人Av资源网站无码软件| 人妻系列无码专区久久五月天| 国产精品内射久久久久欢欢| 久久久91精品国产一区二区三区| 伊人伊成久久人综合网777| 青青热久久国产久精品| 精品一区二区久久| 亚洲国产精品无码久久| 一级A毛片免费观看久久精品| 天天久久狠狠色综合| 国产一久久香蕉国产线看观看| 午夜精品久久久久久99热| 久久精品国产精品亚洲精品| 思思久久99热免费精品6| 国产精品无码久久久久| 久久综合狠狠综合久久激情 | 久久久久久久97| AV色综合久久天堂AV色综合在| 国产亚洲精品久久久久秋霞| 精品国产青草久久久久福利| 国内精品久久久久影院薰衣草|