• <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)過時了,我不這樣認(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類型,而不用回頭去看變量定義,這樣,看代碼時就會很快。
            而且,對于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)在體會還不深,可能是對的。

            今天(2006 04 13碰巧看到codeproject的一個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上面有兩個鏈接
            Conversations: Hungarian wartHogs (http://www.cuj.com/documents/s=7989/cujcexp1911hyslop/hyslop.htm)
            號稱這篇文章就已經(jīng)明白的說HN過時了(作者也是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 閱讀(606) 評論(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)是使代碼看起來是一個人寫的。  回復(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ù)性的主要作用因素.
            清晰、可理解的代碼可以表示為以下三個簡單的基礎(chǔ)原理
            最小混淆 - 它的生存期中,源代碼的讀遠(yuǎn)比寫多,規(guī)約更是這樣。理想情況下,源代碼讀起來應(yīng)該象英語一樣描述了所要做的事,這同時還帶來了它執(zhí)行的好處。程序更多是為人編寫,而不是為計算機(jī)而編寫。閱讀代碼是一個復(fù)雜的腦力過程,它可由統(tǒng)一標(biāo)準(zhǔn)來簡化,在本文中還指最小混淆原則。整個項目中統(tǒng)一樣式是軟件開發(fā)團(tuán)隊在編程標(biāo)準(zhǔn)上達(dá)成一致的主要原因,它不應(yīng)視為一種懲罰或?qū)?chuàng)造性和生產(chǎn)力的阻礙。
            維護(hù)的唯一點(diǎn) - 只要可能,設(shè)計決策就應(yīng)在源中只表述一點(diǎn),它的多數(shù)后果應(yīng)程序化的派生于此點(diǎn)。不遵守這一原則嚴(yán)重?fù)p害了可維護(hù)性、可靠性和可理解性。
            最小干擾 - 最終,應(yīng)用最小干擾原則(它是易讀性的主要作用因素)。即,避免將源代碼與可視干擾(如內(nèi)容較少或?qū)斫廛浖康牟黄鹱饔玫男畔ⅲ┫嗷旌希?

            去年得了jolt大獎的 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),能有具體例子說明一下嗎?

            估計HN真的正在慢慢的過時,在codeproject中的一個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
            有空多交流這個話題,我要整理之后才能給出一個自已覺得滿意點(diǎn)的回復(fù).
            晚些時候再來個詳細(xì)的.   回復(fù)  更多評論
              

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

            欧美日韩中文字幕久久久不卡 | 亚洲综合久久夜AV | 精品久久久噜噜噜久久久| 日批日出水久久亚洲精品tv| yellow中文字幕久久网| 久久精品这里热有精品| 精品久久久久久久久中文字幕| 久久66热人妻偷产精品9| 久久99亚洲网美利坚合众国| 日本久久久久亚洲中字幕| 日本五月天婷久久网站| 精品熟女少妇AV免费久久| 无码人妻久久一区二区三区免费| 亚洲精品午夜国产VA久久成人| 久久午夜羞羞影院免费观看| 久久w5ww成w人免费| 青青国产成人久久91网| 99久久免费只有精品国产| 亚洲一区二区三区日本久久九| 人人狠狠综合久久亚洲88| 久久人搡人人玩人妻精品首页| 一本色道久久88综合日韩精品 | 91久久九九无码成人网站| 办公室久久精品| 久久精品桃花综合| 精品国产VA久久久久久久冰 | 亚洲天堂久久精品| 亚洲精品99久久久久中文字幕 | 色播久久人人爽人人爽人人片aV | 久久人妻无码中文字幕| 久久夜色精品国产噜噜噜亚洲AV| 久久精品男人影院| 久久毛片免费看一区二区三区| 欧美亚洲国产精品久久高清| 久久99热只有频精品8| 久久久91人妻无码精品蜜桃HD | 日本久久久精品中文字幕| 日韩亚洲国产综合久久久| 欧美大香线蕉线伊人久久| 久久99精品久久久久久水蜜桃| 久久99精品久久久大学生|