• <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)可以很好的檢測(cè)出類型的不匹配,或者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ì)很快。
            而且,對(duì)于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ì)還不深,可能是對(duì)的。

            今天(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)
            號(hào)稱這篇文章就已經(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 閱讀(604) 評(píng)論(5)  編輯 收藏 引用 所屬分類: C++ Coding Standards

            Feedback

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

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

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

            # 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)格作了批評(píng).


              回復(fù)  更多評(píng)論
              

            # 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ù)  更多評(píng)論
              

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

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

            色成年激情久久综合| 亚洲精品成人久久久| 久久久久免费精品国产| 久久播电影网| 国产成人99久久亚洲综合精品| 久久99国产精品久久久| 色婷婷久久综合中文久久蜜桃av| 亚洲伊人久久大香线蕉综合图片| 久久天天躁夜夜躁狠狠| 狠狠色丁香久久婷婷综合_中| 婷婷久久综合| 偷窥少妇久久久久久久久| 2021国产精品午夜久久| 伊人久久大香线蕉综合影院首页 | 欧美精品久久久久久久自慰| 久久妇女高潮几次MBA| 久久国产免费直播| 国产精品一区二区久久国产| 狠狠色婷婷综合天天久久丁香| 久久成人国产精品二三区| 国产精品成人无码久久久久久 | 久久人搡人人玩人妻精品首页| 精品一久久香蕉国产线看播放| 久久久久亚洲AV成人网人人软件 | 久久国产亚洲精品| 无码人妻精品一区二区三区久久久| 久久w5ww成w人免费| 一本一道久久精品综合| 亚洲精品NV久久久久久久久久 | 久久www免费人成精品香蕉| 日韩精品久久久久久久电影| 久久婷婷五月综合色高清| 久久精品一区二区国产| 婷婷久久综合九色综合九七| 色狠狠久久AV五月综合| 国产综合精品久久亚洲| 久久精品国产免费观看三人同眠| 精品999久久久久久中文字幕| 日韩久久无码免费毛片软件| 色偷偷偷久久伊人大杳蕉| 色综合色天天久久婷婷基地|