精华内容
下载资源
问答
  • 匈牙利命名法优缺点

    千次阅读 2011-06-05 08:24:00
    查看文章 [转]匈牙利命名法优缺点 2011/03/24 13:57转:http://blogold.chinaunix.net/u/13621/showart_1005794.html 虽然极度讨厌遵照匈牙利命名法写的代码,但是公司的编码规范的命名部分是遵照匈牙利约定的,...
    查看文章
    [转]匈牙利命名法的优缺点
    2011/03/24 13:57

    转:http://blogold.chinaunix.net/u/13621/showart_1005794.html

     

    虽然极度讨厌遵照匈牙利命名法写的代码,但是公司的编码规范的命名部分是遵照匈牙利
    约定的,所以还是硬着头皮去客观的了解一下;

    9.5.5  匈牙利约定优点
        匈牙利约定与其它命名约定一样,拥有由命名约定所带来的一切共同优点。由于有这样
    多的标准名称,因此在任何一个单个子程序或程序中要特殊记忆的名字是非常少的。匈牙利
    约定完全可以在不同项目中采用。
        匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对
    First,Min,Last,Max 和 Lim 的准确区分在实际中是尤其有帮助的。匈牙利约定可以使
    人对编译程序无法检查的抽象数据类型进行检查:cpaReformat[i]很可能是错误的,因为
    cpaReformat 不是数组,而 apaReformat[i]则可能是正确的,因为 apaReformat[i]是数
    组。
        匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如,在 Windows 环
    境下编程时,需要你放弃许多类型,这极大地限制了编译程序进行严格类型检查的能力。
    而建立约定则可以对环境的这一弱点作出补偿,匈牙利约定还可以使名称更简洁,可以用
    CMedals 而不用 TotalMedals 来代表奖牌的数量,使用 pNewScore,而不是用
    NewScorePtr 命名一个新分数指针。

    9.5.6 匈牙利约定缺点
        一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言
    中整型、长整型、浮点数和字符串为基础来建立基本类型。匈牙利约定基本类型事实上是
    没有什么价值的,因为它使得程序员陷入对类型进行人工检查的困扰之中,而不是让编译
    程序对类型进行更加快速而又准确的检查。
        这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如,说
    明某一变量是整型的,把它改为长整型的时,不得不改动这一变量的名称。
        匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序
    员用hwnd 来命名对窗口的操作时,往往忽视了他所指的到底是哪种窗口、对话框、菜单还
    是帮助区的屏幕?显然用 hwndmenu 要比 hwnd 清楚得多。以变量的意义为代价来获得对
    其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义
    和精确的类型。


    ================================================================================
    几年以前,Charles Simonyi(他后来成为微软的著名程序员)设计了一种以前缀为基础的命名
    方法,这种方法后来称为"匈牙利表示法"以记念他.他的思想是根据每个标识符所代表的含义
    给它一个前缀.微软后来采用了这个思想,给每个标识符一个前缀以说明它的数据类型.因此,
    整型变量的前缀是n,长整型变量是nl,字符型数组变量是ca,以及字符串(以空类型结尾的字
    符数组)以sz为前缀.这些名字可能会非常古怪.比如说:lpszFoo表示"Foo"是一个指向以空字
    符为结尾的字符串的长整型指针.

    这种方法的优点是使人能够通过变量的名字来辨别变量的类型,而不比去查找它的定义.遗憾
    的是,这种方法不仅使变量名字非常绕口,而且使改变变量类型的工作变得十分艰巨.在
    Windows3.1中,整型变量为16为宽.如果我们在开始时采用了一个整型变量,但是在通过
    30---40个函数的计算之后,发现采用整型变量宽度不够,这时我们不仅要改变这个变量的类
    型,而且要改变这个变量在这30--40个函数中的名字.

    因为不切实际,除了一些顽固的Windows程序员外已经没有人再使用"匈牙利表示法"了.毫无
    疑问,在某种场合它依然存在,但大部分人现在已经抛弃它了.一般而言,输入前缀是一种糟糕
    的想法,因为它把变量于其类型紧紧地绑在了一起.

    对于30行以下的函数,匈牙利方法一般有优势。
    尤其是对界面编程,有优势。
    但对于有强烈的算法要求、尤其是有很多抽象类型的C++程序,匈牙利方法简直是一个灾难。
    看你用在什么地方。
    现在有了很好的IDE工具,如:VC,SourceInsight等.
    选中变量,会自动提示告诉你它的声明和定义,这样
    匈牙利命名法就没有很大的必要了.
    无非就是为了程序可读性较好.
    实际上良好的代码书写习惯比强制使用匈牙利命名法更重要.
    系统性。整体性。可读性。分类要清楚。要有注释!

    --------------------------------------------------------------------------------
    匈牙利命名法是微软推广的一种关于变量、函数、对象、前缀、宏定义等各种类型的符号的
    命名规范。匈牙利命名法的主要思想是:在变量和函数名中加入前缀以增进人们对程序的理
    解。它是由微软内部的一个匈牙利人发起使用的,结果它在微软内部逐渐流行起来,并且推
    广给了全世界的Windows开发人员。下面将介绍匈牙利命名法,后面的例子里也会尽量遵守
    它和上面的代码风格。

      a       Array                                 数组

      b       BOOL (int)                            布尔(整数)

      by      Unsigned Char (Byte)                  无符号字符(字节)

      c       Char                                  字符(字节)

      cb      Count of bytes                        字节数

      cr      Color reference value                 颜色(参考)值

      cx      Count of x (Short)                    x的集合(短整数)

      dw      DWORD   (unsigned long)                 双字(无符号长整数)

      f       Flags   (usually multiple bit values)   标志(一般是有多位的数值)

      fn      Function                              函数

      g_      global                                全局的

      h       Handle                                句柄

      i       Integer                               整数

      l       Long                                  长整数

      lp      Long pointer                          长指针

      m_      Data member of a class                一个类的数据成员

      n       Short int                             短整数

      p       Pointer                               指针

      s       String                                字符串

      sz      Zero terminated String                以0结尾的字符串

      tm      Text metric                           文本规则

      u       Unsigned int                          无符号整数

      ul      Unsigned long (ULONG)                 无符号长整数

      w       WORD (unsigned short)                 无符号短整数

      x,y     x, y coordinates (short)              坐标值/短整数

      v       void                                  空
     

    有关项目的全局变量用g_开始,类成员变量用m_,局部变量若函数较大则可考虑用l_用以
    显示说明其是局部变量。

    前缀       类型       例子

    g_    全局变量       g_Servers

    C     类或者结构体       CDocument,CPrintInfo

    m_   成员变量       m_pDoc,m_nCustomers

     

    VC常用前缀列表:

    前缀       类型       描述       例子

    ch    char 8位字符    chGrade

    ch    TCHAR       16位UNICODE类型字符       chName

    b     BOOL       布尔变量       bEnabled

    n     int    整型(其大小由操作系统决定)       nLength

    n     UINT       无符号整型(其大小由操作系统决定)       nLength

    w    WORD       16位无符号整型    wPos

    l      LONG       32位有符号整型    lOffset

    dw   DWORD       32位无符号整型       dwRange

    p     *       Ambient memory model pointer 内存模块指针,指针变量    pDoc

    lp     FAR*       长指针       lpDoc

    lpsz  LPSTR       32位字符串指针       lpszName

    lpsz  LPCSTR       32位常量字符串指针       lpszName

    lpsz  LPCTSTR       32位UNICODE类型常量指针       lpszName

    h     handle       Windows对象句柄       hWnd

    lpfn  (*fn)()  回调函数指针 Callback Far pointer to CALLBACK function lpfnAbort

     

    Windows对象名称缩写:

    Windows对象       例子变量       MFC类       例子对象

    HWND    hWnd;       CWnd*       pWnd;

    HDLG     hDlg;       CDialog*       pDlg;

    HDC       hDC;       CDC*       pDC;

    HGDIOBJ       hGdiObj;       CGdiObject*     pGdiObj;

    HPEN     hPen;       CPen*       pPen;

    HBRUSH hBrush;       CBrush*       pBrush;

    HFONT   hFont;       CFont*       pFont;

    HBITMAP       hBitmap;       CBitmap*       pBitmap;

    HPALETTE       hPalette;       CPalette*       pPalette;

    HRGN     hRgn;       CRgn*       pRgn;

    HMENU hMenu;       CMenu*       pMenu;

    HWND    hCtl;       CStatic*       pStatic;

    HWND    hCtl;       CButton*       pBtn;

    HWND    hCtl;       CEdit*       pEdit;

    HWND    hCtl;       CListBox*       pListBox;

    HWND    hCtl;       CComboBox*       pComboBox;

     

    VC常用宏定义命名列表:

    前缀       符号类型       符号例子       范围

    IDR_      标识多个资源共享的类型       IDR_MAINFRAME       1~0x6FFF

    IDD_      对话框资源(Dialog)       IDD_SPELL_CHECK       1~ 0x6FFF

    HIDD_    基于对话框的上下文帮助       HIDD_SPELL_CHECK       0x20001~0x26FF

    IDB_       位图资源(Bitmap)       IDB_COMPANY_LOGO       1~0x6FFF

    IDC_      光标资源(Cursor)       IDC_PENCIL    1~0x6FFF

    IDI_       图标资源(Icon)       IDI_NOTEPAD 1~0x6FFF

    ID_、IDM_    工具栏或菜单栏的命令项    ID_TOOLS_SPELLING       0x8000~0xDFFF

    HID_      命令上下文帮助       HID_TOOLS_SPELLING       0x18000~0x1DFFF

    IDP_       消息框提示文字资源       IDP_INVALID_PARTNO       8~0xDFFF

    HIDP_    消息框上下文帮助       HIDP_INVALID_PARTNO       0x30008~0x3DFFF

    IDS_       字符串资源(String)       IDS_COPYRIGHT       1~0x7FFF

    IDC_      对话框内的控制资源       IDC_RECALC   8~0xDFFF

     

    Microsoft MFC宏命名规范

    名称       类型

    _AFXDLL       唯一的动态连接库(Dynamic Link Library,DLL)版本

    _ALPHA  仅编译DEC Alpha处理器

    _DEBUG 包括诊断的调试版本

    _MBCS   编译多字节字符集

    _UNICODE       在一个应用程序中打开Unicode

    AFXAPI  MFC提供的函数

    CALLBACK       通过指针回调的函数

     

    库标识符命名法

    标识符    值和含义

    u     ANSI(N)或Unicode(U)

    d     调试或发行:D = 调试;忽略标识符为发行

     

    静态库版本命名规范

    库    描述

    NAFXCWD.LIB       调试版本:MFC静态连接库

    NAFXCW.LIB       发行版本:MFC静态连接库

    UAFXCWD.LIB       调试版本:具有Unicode支持的MFC静态连接库

    UAFXCW.LIB       发行版本:具有Unicode支持的MFC静态连接库

     

    动态连接库命名规范

    名称       类型

    _AFXDLL       唯一的动态连接库(DLL)版本

    WINAPI       Windows所提供的函数

     

    Windows.h中新的命名规范

    类型       定义描述

    WINAPI  使用在API声明中的FAR PASCAL位置,如果正在编写一个具有导出API人口点的DLL
    ,则可以在自己的API中使用该类型

    CALLBACK       使用在应用程序回调程序,如窗口和对话框过程中的FAR PASCAL的位置

    LPCSTR 与LPSTR相同,只是LPCSTR用于只读串指针,其定义类似(const char FAR*)

    UINT      可移植的无符号整型类型,其大小由主机环境决定(对于Windows NT和Windows
                                                9x为32位);它是unsigned int的同义词

    LRESULT       窗口程序返回值的类型

    LPARAM 声明lParam所使用的类型,lParam是窗口程序的第四个参数

    WPARAM       声明wParam所使用的类型,wParam是窗口程序的第三个参数

    LPVOID  一般指针类型,与(void *)相同,可以用来代替LPSTR

     

    MSDN中给出了一段遵守代码风格和匈牙利命名法的代码参考如下:
    1   #include “sy.h”
    2   extern int *rgwDic;
    3   extern int bsyMac;
    4   struct SY *PsySz(char sz[])
    6   {
    7       char *pch;
    8       int cch;
    9       struct SY *psy, *PsyCreate();
    10      int *pbsy;
    11      int cwSz;
    12      unsigned wHash=0;
    13      pch=sz;
    14      while (*pch!=0)
    15          wHash=wHash<>11+*pch++;
    16      cch=pch-sz;
    17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
    18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
    19      {
    20          char *szSy;
    21          szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
    22          pch=sz;
    23          while (*pch==*szSy++)
    24          {
    25              if (*pch++==0)
    26                  return (psy);
    27          }
    28      }
    29      cwSz=0;
    30      if (cch>=2)
    31          cwSz=cch-2/sizeof(int)+1;
    32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
    33      Zero((int *)psy,cwSY);
    34      bltbyte(sz, psy->sz, cch+1);
    35      return(psy);
    36  }

    展开全文
  • 匈牙利命名法

    2019-05-11 14:28:33
    匈牙利命名法是电脑程序设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法和匈牙利应用命名法。 匈牙利命名法具备语言独立的特性,并且首次在BCPL语言中被大量使用。由于BCPL只有机器字这一种数据...

    匈牙利命名法是电脑程序设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法匈牙利应用命名法

    匈牙利命名法具备语言独立的特性,并且首次在BCPL语言中被大量使用。由于BCPL只有机器字这一种数据类型,因此这种语言本身无法帮助程序员来记住变量的类型。匈牙利命名法通过明确每个变量的数据类型来解决这个问题。

    在匈牙利命名法中,一个变量名由一个或多个小写字母开始,这些字母有助于记忆变数的类型和用途,紧跟着的就是程序员选择的任何名称。这个后半部分的首字母可以大写,以区别前面的类型指示字母(驼峰式大小写)。

    历史

    原始的匈牙利命名法,现在被称为匈牙利应用命名法,由1972年至1981年在施乐帕洛阿尔托研究中心工作的-程序员查尔斯·西蒙尼发明。此人后来成了微软的总设计师。

    这种命名法其实是对于西蒙尼祖籍的一种讽刺。匈牙利人名和大多数其他欧洲人名相比是反过来的,即姓氏在名字的前面。举个例子,英语化的名字“Charles Simonyi”在匈牙利语中原本是“Simonyi Károly”。同样的,在匈牙利命名法中,类型名在实际变量名前,而不是像大多数欧洲的Smalltalk那样,类型放在变量名后,例如aPointlastPoint。后者在西蒙尼任职于施乐帕洛阿尔托研究中心时期非常流行。这种命名法的灵感,可能是受波兰表示法的启发。

    系统匈牙利命名法与匈牙利应用命名法

    系统命名法与应用命名法的区别在于前缀的目的

    系统匈牙利命名法中,前缀代表了变量的实际数据类型。例如:

    • lAccountNum:变量是一个长整数(“l”);
    • arru8NumberList:变量是一个无符号8位整型数组(“arru8”);
    • szName:变量是一个零结束字符串(“sz”),这是西蒙尼最开始建议的前缀之一。

    匈牙利应用命名法不表示实际数据类型,而是给出了变量目的的提示,或者说它代表了什么。

    • rwPosition:变量代表一个行(“rw”)。
    • usName:变量代表一个非安全字符串(“us”),需要在使用前处理。
    • strName:变量代表一个包含名字的字符串(“str”)但是没有指明这个字符串是如何实现的。

    西蒙尼建议的大多数前缀都是自然语义的,但不是所有。下面几个是来自原始论文的:

    • pX是指向另一个X类型的指针,这包含非常少的语义信息。
    • d是一个前缀表示两个值的区别,例如,dY可能代表一个图形沿Y轴的距离,而一个仅仅叫做y的变量可能是一个绝对坐标。这完全是自然语义的。
    • sz是一个无结束或零结束的字符串。在C中,这包含一些语义信息,因为它不是很明确一个char*类型的变量是一个指向单个字符的指针,还是一个字符数组,或是一个零结束字符串。
    • w标记一个变量是一个字。这基本上没有包含什么语义信息,因此大概会被当成是系统命名法。
    • b标记了一个字节,和w对比可能有一些语义信息,因为C语言中,只有字节大小的数据是char型的,因此这些有时候被用来保存数值。这个前缀也许可以明确某个变量保存的是应该被看作是字母(或更一般的字符)的数值还是一个数字。

    由于这种命名法通常使用小写字母开头用来助记,但是并没有对助记符本身作规定。有几种被广泛使用的习惯(见下面的示例),但是任意字母组合都可以被使用,只要它们在代码主体中保持一致就可以了。

    在使用匈牙利应用命名法的代码中有时候也可能包含系统匈牙利命名法。

    示例

    • bBusy:布尔型
    • cApples:项目计数
    • dwLightYears:双字(系统)
    • fBusy:布尔型(标记)
    • nSize:整型(系统)或计数(应用程序)
    • iSize:整型(系统)或索引(应用程序)
    • fpPrice:浮点数
    • dbPi:双精度浮点数(系统)
    • pFoo:指针
    • rgStudents:数组或范围
    • szLastName:零结束字符串
    • u32Identifier:无符号32位整型(系统)
    • stTime:时钟结构
    • fnFunction:函数名

    对于指针和数组来说,它们实际上并不是数据类型,因此通常在助记符后面跟着实际元素的类型。

    • pszOwner:指向零结束字符串的指针
    • rgfpBalances:浮点值的数组

    由于匈牙利命名法可以被应用在任何程序设计语言和环境中,因此被微软广泛用在C语言中,特别是在Microsoft Windows里。由此一来,许多常见的匈牙利命名法的结构都和Windows紧密相关:

    • hwndFoo:窗口句柄
    • lpszBar:指向零结束字符串的长指针

    这种命名法又在C++中被扩展进而包含变量的作用域,由一个下划线隔开:

    • g_nWheels:全局命名空间的成员,整型
    • m_nWheels:结构体/类成员,整型

    系统匈牙利命名法的优点

    (其中一些只适用于系统匈牙利命名法) 支持者声称匈牙利命名法的好处包括:

    • 从名字中就可以看出变量的类型

    • 拥有类似语义的多个变量可以在一个代码块中使用:dwWidth,iWidth,fWidth,dWidth

    • 变量名在仅仅知道他们的类型时可以被轻易记住

    • 可以使变量名更加一致

    • 决定一个变量名的时候可以更机械化,更快

    • 不合适的类型转换和操作可以在阅读代码的时候被检测出来

    • 在那些数字被当作字符串处理的基于字符串的语言中非常有用(例如Tcl)

    • 在匈牙利应用命名法中,变量名确保不会犯以下错误:

        heightWindow = window.getWidth()
      
    • 在使用动态类型语言或完全无类型的语言编程时,关于类型的修饰可以更简化。这种语言一般不包含类型修饰(或者可选),因此唯一可以看出哪些类型是被允许的只有名字本身、文档以及通过阅读代码来明白它们在做什么。在这些语言中,包含对于变量类型的指示可能会有助于程序员。就像上面提到的,匈牙利命名法扩展了这样的语言(BCPL)。

    • 在包含许多全局对象的复杂程序中(VB/Delphi Forms),拥有一个基本的前缀命名法可以简化在编辑器中查找组件的工作。按btn可以使编辑器弹出一个Button对象的列表。

    匈牙利系统命名法的缺点

    批评者认为:

    • 匈牙利命名法在编译器做类型检查时是多余的。一个提供类型检查的语言在确定一个变量与其类型一致时,比人眼仅仅检查变量的用法与变量名一致要强大的多。
    • 一些现代的集成开发环境,如Visual Studio在需要时可以显示变量类型,并且自动标记不匹配的类型。使用这种命名法完全没有必要。
    • 匈牙利命名法在被用作代表多个属性的时候会造成困惑,如 a_crszkvc30LastNameCol:一个常量引用参数,保存了一个varchar(30)类型的数据库列LastName的内容,而这列又是这个表的主键的一部分。
    • 在代码更改后可能造成不一致。如果一个变量的类型改变了,不是变量名的修饰与新的类型不一致,就是变量名必须被改变。
    • 由于变量名和类型捆绑在一起,因此不利于代码的移植。一个典型的众所周之的例子就是WPARAM类型,以及在许多Windows系统函数声明中使用的wParam参数。它原本是一个16位的类型,但是在后来的操作系统中被改成了32位或64位,但仍保留原来的名字(它实际的基础类型是UINT_PTR,即一个大小足够保存一个指针的无符号整型)。
    • 大多数时候,看到一个变量就意味着知道了它的类型。但是,如果你不知道一个变量是干什么的,知道了它的类型也没什么帮助。

    .NET Framework,微软新的软件开发平台,除了接口类型一般不适用匈牙利命名法。在.NET中,习惯在接口类型前放一个I(例如Windows Forms中的IButtonControl接口。).NET Framework指导方针建议程序员不要用匈牙利命名法,但是没有指明不要用系统匈牙利命名法还是匈牙利应用命名法,或者是两者都不要用。与此对比,Java的标准库中连接口类型也不加前缀。

    展开全文
  • C语言编程规范之匈牙利命名法

    千次阅读 2018-09-20 17:12:37
    匈牙利命名法   匈牙利命名法是一种编程时的命名规范。基本原则是:变量名=属性+类型+对象描述,其中每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。要基于容易记忆容易理解的原则。保证名字...

    匈牙利命名法 
        匈牙利命名法是一种编程时的命名规范。基本原则是:变量名=属性+类型+对象描述,其中每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。

    例子
    举例来说,表单的名称为form,那么在匈牙利命名法中可以简写为frm,则当表单变量名称为Switchboard时,变量全称应该为 frmSwitchboard。这样可以很容易从变量名看出Switchboard是一个表单,同样,如果此变量类型为标签,那么就应命名成 lblSwitchboard。可以看出,匈牙利命名法非常便于记忆,而且使变量名非常清晰易懂,这样,增强了代码的可读性,方便各程序员之间相互交流代码。
    Charles Simonyi
    Charles Simonyi
    历史
    据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的,后来他在微软呆了几年,于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。大部分程序员不管自己使用什么软件进行开发,或多或少都使用了这种命名法。这种命名法的出发点是把变量名按:属性+类型+对象描述的顺序组合起来,以使程序员作变量时对变量的类型和其它属性有直观的了解,下面是HN变量命名规范。

    变量属性编辑
    属性部分:
    g_ 全局变量
    c_  常量
    m_  c++类成员变量
    s_  静态变量
    类型部分:
    数组 a
    指针 p
    函数 fn
    无效 v
    句柄 h
    长整型 l
    布尔 b
    浮点型(有时也指文件) f
    双字  dw
    字符串  sz
    短整型  n
    双精度浮点 d
    计数 c(通常用cnt)
    字符 ch(通常用c)
    整型 i(通常用n)
    字节 by
    字 w
    实型 r
    无符号 u
    描述部分:
    最大 Max
    最小 Min
    初始化 Init
    临时变量 T(或Temp)
    源对象 Src
    目的对象 Dest


    举例编辑
    hwnd : h 是类型描述,表示句柄, wnd 是变量对象描述,表示窗口,所以 hwnd 表示窗口句柄;
    pfnEatApple : pfn 是类型描述,表示指向函数的指针, EatApple 是变量对象描述,所以它表示指向
    EatApple 函数的函数指针变量。
    g_cch : g_ 是属性描述,表示全局变量,c 和 ch 分别是计数类型和字符类型,一起表示变量类型,这里忽略了对象描述,所以它表示一个对字符进行计数的全局变量。
    上面就是HN命名法的一般规则。


    总结编辑
    MFC、句柄、控件及结构的命名规范:
    Windows类型 样本变量;MFC类 样本变量
    HWND hWnd; CWnd* pWnd;
    HDLG hDlg; CDialog* pDlg;
    HDC hDC; CDC* pDC;
    HGDIOBJ hGdiObj; CGdiObject* pGdiObj;
    HPEN hPen; CPen* pPen;
    HBRUSH hBrush; CBrush* pBrush;
    HFONT hFont; CFont* pFont;
    HBITMAP hBitmap; CBitmap* pBitmap;
    HPALETTE hPaltte; CPalette* pPalette;
    HRGN hRgn; CRgn* pRgn;
    HMENU hMenu; CMenu* pMenu;
    HWND hCtl; CState* pState;
    HWND hCtl; CButton* pButton;
    HWND hCtl; CEdit* pEdit;
    HWND hCtl; CListBox* pListBox;
    HWND hCtl; CComboBox* pComboBox;
    HWND hCtl; CScrollBar* pScrollBar;
    HSZ hszStr; CString pStr;
    POINT pt; CPoint pt;
    SIZE size; CSize size;
    RECT rect; CRect rect;

    一般前缀命名规范:

    前缀&类型&实例

    C 类或结构 CDocument,CPrintInfo
    m_ 成员变量 m_pDoc,m_nCustomers
    变量命名规范:
    前缀&类型&描述&实例
    ch char 8位字符 chGrade
    ch TCHAR 如果_UNICODE定义,则为16位字符 chName
    b BOOL 布尔值 bEnable
    n int 整型(其大小依赖于操作系统) nLength
    u UINT 无符号值(其大小依赖于操作系统) uHeight
    w WORD 16位无符号值 wPos
    l LONG 32位有符号整型 lOffset
    dw DWORD 32位无符号整型 dwRange
    p * 指针 pDoc
    lp FAR* 远指针 lpszName
    lpsz LPSTR 32位字符串指针 lpszName
    lpsz LPCSTR 32位常量字符串指针 lpszName
    lpsz LPCTSTR 如果_UNICODE定义,则为32位常量字符串指针 lpszName
    h handle Windows对象句柄 hWnd
    lpfn callback 指向CALLBACK函数的远指针
    前缀_符号类型:
    前缀_符号类型实例&范围
    IDR_ 不同类型的多个资源共享标识 IDR_MAIINFRAME 1~0x6FFF
    IDD_ 对话框资源 IDD_SPELL_CHECK 1~0x6FFF
    HIDD_ 对话框资源的Help上下文 HIDD_SPELL_CHECK 0x20001~0x26FF
    IDB_ 位图资源 IDB_COMPANY_LOGO 1~0x6FFF
    IDC_ 光标资源 IDC_PENCIL 1~0x6FFF
    IDI_ 图标资源 IDI_NOTEPAD 1~0x6FFF
    ID_ 来自菜单项或工具栏的命令 ID_TOOLS_SPELLING 0x8000~0xDFFF
    HID_ 命令Help上下文 HID_TOOLS_SPELLING 0x18000~0x1DFFF
    IDP_ 消息框提示 IDP_INVALID_PARTNO 8~0xDEEF
    HIDP_ 消息框Help上下文 HIDP_INVALID_PARTNO 0x30008~0x3DEFF
    IDS_ 串资源 IDS_COPYRIGHT 1~0x7EEF
    IDC_ 对话框内的控件 IDC_RECALC 8~0xDEEF

    Microsoft MFC宏命名规范:

    名称&类型

    _AFXDLL 唯一的动态连接库(Dynamic Link Library,DLL)版本
    _ALPHA 仅编译DEC Alpha处理器
    _DEBUG 包括诊断的调试版本
    _MBCS 编译多字节字符集
    _UNICODE 在一个应用程序中打开Unicode
    AFXAPI MFC提供的函数
    CALLBACK 通过指针回调的函数
    库标识符命名法:
    标识符&值和含义
    u ANSI(N)或Unicode(U)
    d 调试或发行:D = 调试;忽略标识符为发行。
    静态库版本命名规范:
    库&描述
    NAFXCWD.LIB 调试版本:MFC静态连接库
    NAFXCW.LIB 发行版本:MFC静态连接库
    UAFXCWD.LIB 调试版本:具有Unicode支持的MFC静态连接库
    UAFXCW.LIB 发行版本:具有Unicode支持的MFC静态连接库
    动态连接库命名规范:
    名称&类型
    _AFXDLL 唯一的动态连接库(DLL)版本
    WINAPI Windows所提供的函数
    Windows.h中新的命名规范:
    类型&定义描述
    WINAPI 使用在API声明中的FAR PASCAL位置,如果正在编写一个具有导出API人口点的DLL,则可以在自己
    的API中使用该类型
    CALLBACK 使用在应用程序回叫例程,如窗口和对话框过程中的FAR PASCAL的位置
    LPCSTR 与LPSTR相同,只是LPCSTR用于只读串指针,其定义类似(const char FAR*)
    UINT 可移植的无符号整型类型,其大小由主机环境决定(对于Windows NT和Windows 9x为32位);它是
    unsigned int的同义词
    LRESULT 窗口程序返回值的类型
    LPARAM 声明lParam所使用的类型,lParam是窗口程序的第四个参数
    WPARAM 声明wParam所使用的类型,wParam是窗口程序的第三个参数
    LPVOID 一般指针类型,与(void *)相同,可以用来代替LPSTR
    反对声音编辑
    匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃
    兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名
    规范,也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞
    鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力
    要大得多。
    有人认为,匈牙利命名法是一个坏的命名规范。举例说明。以静态强类型编程语言为例,分析范本为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语
    言并没有非常严格地区分不同的指针类型。
    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) 这一条来用匈牙利命名法命名,难度极大。
    5.类型修饰:static,extern,mutable,register,volatile,const,short,long,unsigned 加上类型修饰,
    更是难上加难。
    匈牙利命名法有其优点但也有缺点,这就需要在使用中扬长避短,合理应用它。

    展开全文
  • 系统匈牙利命名法

    2013-08-27 00:44:31
    注:据维基百科所说那么百度百科所说的都是系统匈牙利命名法,据此本人斗胆将以下文中名词“匈牙利命名法”均改为“系统匈牙利命名法”,在维基百科里面此方面不够详细,所以引用百度百科。 简介  原则  历史  ...

    据维基百科所说那么百度百科所说的都是系统匈牙利命名法,据此本人斗胆将以下文中名词“匈牙利命名法”均改为“系统匈牙利命名法”,在维基百科里面此方面不够详细,所以引用百度百科。并且做了符合个人习惯的篇幅修改,但是内容一个字都不变,解释权归百度百科所有

    原则

    系统匈牙利命名法是一种编程时的命名规范。基本原则是: 变量名=属性+类型+对象描述,其中每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。
    举例来说,表单的名称为form,那么在 系统 匈牙利 命名法中可以简写为frm,则当表单 变量名称为Switchboard时,变量全称应该为 frmSwitchboard。这样可以很容易从 变量名看出Switchboard是一个表单,同样,如果此变量类型为标签,那么就应命名成 lblSwitchboard。可以看出, 系统 匈牙利 命名法非常便于记忆,而且使 变量名非常清晰易懂,这样,增强了代码的可读性,方便各程序员之间相互交流代码。

    历史

    据说这种命名法是一位叫 Charles Simonyi 的 匈牙利程序员发明的,后来他在 微软呆了几年,于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在,大部分 程序员不管自己使用什么 软件进行开发,或多或少都使用了这种命名法。这种命名法的出发点是把 变量名按:属性+类型+对象描述的顺序组合起来,以使程序员作变量时对变量的类型和其它属性有直观的了解,下面是HN变量命名规范。

    变量属性

    属性部分:

    c_   常量
    m_  c++类 成员变量
    s_   静态变量

    类型部分:

    指针 p
    函数 fn
    无效 v
    句柄 h
    长整型 l
    布尔 b
    浮点型(有时也指文件) f
    双字  dw
    字符串  sz
    短整型  n
    双精度浮点 d
    计数 c(通常用cnt)
    字符 ch(通常用c)
    整型 i(通常用n)
    字节 by
    字 w
    实型 r
    无符号 u

    描述部分:

    最大 Max
    最小 Min
    初始化 Init
    临时变量 T(或Temp)
    源对象 Src
    目的对象 Dest

    举例

    hwnd : h 是类型描述,表示句柄, wnd 是 变量对象描述,表示窗口,所以 hwnd 表示 窗口句柄
    pfnEatApple : pfn 是类型描述,表示指向函数的 指针, EatApple 是 变量对象描述,所以它表示指向 EatApple 函数的函数 指针变量
    g_cch : g_ 是属性描述,表示 全局变量,c 和 ch 分别是计数类型和 字符类型,一起表示变量类型,这里忽略了对象描述,所以它表示一个对字符进行计数的全局变量。
    上面就是HN命名法的一般规则。

    总结

          MFC、句柄、控件及结构的命名规范:

    Windows类型 样本变量;MFC类 样本变量
    HWND hWnd; CWnd* pWnd;
    HDLG hDlg; CDialog* pDlg;
    HDC hDC; CDC* pDC;
    HGDIOBJ hGdiObj; CGdiObject* pGdiObj;
    HPEN hPen; CPen* pPen;
    HBRUSH hBrush; CBrush* pBrush;
    HFONT hFont; CFont* pFont;
    HBITMAP hBitmap; CBitmap* pBitmap;
    HPALETTE hPaltte; CPalette* pPalette;
    HRGN hRgn; CRgn* pRgn;
    HMENU hMenu; CMenu* pMenu;
    HWND hCtl; CState* pState;
    HWND hCtl; CButton* pButton;
    HWND hCtl; CEdit* pEdit;
    HWND hCtl; CListBox* pListBox;
    HWND hCtl; CComboBox* pComboBox;
    HWND hCtl; CScrollBar* pScrollBar;
    HSZ hszStr; CString pStr;
    POINT pt; CPoint pt;
    SIZE size; CSize size;
    RECT rect; CRect rect;

         一般前缀命名规范:

    前缀&类型&实例
    C 类或结构 CDocument, CPrintInfo
    m_  成员变量 m_pDoc,m_nCustomers

         变量命名规范

    前缀&类型&描述&实例
    ch char 8位字符 chGrade
    ch TCHAR 如果_UNICODE定义,则为16位 字符 chName
    b BOOL  布尔值 bEnable
    n int  整型(其大小依赖于 操作系统) nLength
    u UINT 无符号值(其大小依赖于 操作系统) uHeight
    w WORD 16位无符号值 wPos
    l LONG 32位有符号整型 lOffset
    dw DWORD 32位无符号整型 dwRange
    p *  指针 pDoc
    lp FAR* 远 指针 lpszName
    lpsz LPSTR 32位字符串指针 lpszName
    lpsz LPCSTR 32位 常量字符串指针 lpszName
    lpsz LPCTSTR 如果_UNICODE定义,则为32位 常量字符串指针 lpszName
    h handle Windows对象句柄 hWnd
    lpfn callback 指向CALLBACK函数的 远指针

         前缀_符号类型:

    前缀_符号类型实例&范围
    IDR_ 不同类型的多个资源共享标识 IDR_MAIINFRAME 1~0x6FFF
    IDD_ 对话框资源 IDD_SPELL_CHECK 1~0x6FFF
    HIDD_ 对话框资源的Help上下文 HIDD_SPELL_CHECK 0x20001~0x26FF
    IDB_ 位图资源 IDB_COMPANY_LOGO 1~0x6FFF
    IDC_ 光标资源 IDC_PENCIL 1~0x6FFF
    IDI_ 图标资源 IDI_NOTEPAD 1~0x6FFF
    ID_ 来自菜单项或 工具栏的命令 ID_TOOLS_SPELLING 0x8000~0xDFFF
    HID_ 命令Help上下文 HID_TOOLS_SPELLING 0x18000~0x1DFFF
    IDP_  消息框提示 IDP_INVALID_PARTNO 8~0xDEEF
    HIDP_  消息框Help上下文 HIDP_INVALID_PARTNO 0x30008~0x3DEFF
    IDS_ 串资源 IDS_COPYRIGHT 1~0x7EEF
    IDC_ 对话框内的控件 IDC_RECALC 8~0xDEEF

          Microsoft MFC宏命名规范:

    名称&类型
    _AFXDLL 唯一的 动态连接库(Dynamic Link Library,DLL)版本
    _ALPHA 仅编译DEC Alpha处理器
    _DEBUG 包括诊断的调试版本
    _MBCS 编译多字节 字符集
    _UNICODE 在一个 应用程序中打开Unicode
    AFXAPI MFC提供的函数
    CALLBACK 通过指针回调的函数

          库标识符命名法:

    标识符&值和含义
    u ANSI(N)或Unicode(U)
    d 调试或发行:D = 调试;忽略 标识符为发行。

         静态库版本命名规范:

    库&描述
    NAFXCWD.LIB 调试版本:MFC静态连接库
    NAFXCW.LIB 发行版本:MFC静态连接库
    UAFXCWD.LIB 调试版本:具有Unicode支持的MFC 静态连接库
    UAFXCW.LIB 发行版本:具有Unicode支持的MFC 静态连接库

          动态连接库命名规范:

    名称&类型
    _AFXDLL 唯一的 动态连接库(DLL)版本
    WINAPI Windows所提供的函数

          Windows.h中新的命名规范:

    类型&定义描述
    WINAPI 使用在API声明中的FAR PASCAL位置,如果正在编写一个具有导出API人口点的DLL,则可以在自己的API中使用该类型
    CALLBACK 使用在 应用程序回叫例程,如窗口和对话框过程中的FAR PASCAL的位置
    LPCSTR 与LPSTR相同,只是LPCSTR用于只读串 指针,其定义类似(const char FAR*)
    UINT 可移植的无符号整型类型,其大小由主机环境决定(对于Windows NT和Windows 9x为32位);它是unsigned int的同义词
    LRESULT 窗口程序返回值的类型
    LPARAM 声明lParam所使用的类型,lParam是窗口程序的第四个参数
    WPARAM 声明wParam所使用的类型,wParam是窗口程序的第三个参数
    LPVOID 一般 指针类型,与(void *)相同,可以用来代替LPSTR

    反对声音

    系统 匈牙利 命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方,自古乃 兵家必争之地。命名规范有何用?四个字:名正言顺。用二分法,命名规范分为好的命名规范和坏的命名规范,也就是说名正言顺的命名规范和 名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋,坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。
    有人认为, 系统 匈牙利 命名法是一个坏的命名规范。举例说明。以 静态强类型编程语言为例,分析范本为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语言并没有非常严格地区分不同的 指针类型。
    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) 这一条来用 系统 匈牙利 命名法命名,难度极大。
    5.类型修饰:static,extern,mutable,register,volatile,const,short,long,unsigned 加上类型修饰,更是难上加难。
    系统 匈牙利 命名法有其优点但也有缺点,这就需要在使用中扬长避短,合理应用它。

    展开全文
  • 匈牙利命名法探讨

    2011-03-31 17:18:00
    匈牙利命名法介绍 匈牙利命名法是计算机程序设计中的一种命名规则,由1972年至1981年在施乐帕洛阿尔托研究中心工作的程序员查尔斯•西蒙尼发明,此人后来成了微软的总设计师。他的思想是根据每个标识符所代表的含义...
  • 匈牙利命名法匈牙利命名法计算器程序设计中的一种命名规则,用这种方法命名的变数显示了其数据类型。匈牙利命名法有两种:系统匈牙利命名法和匈牙利应用命名法。匈牙利命名法被设计成语言独立的,并且首次在BCPL语言...
  • 匈牙利命名法的利与弊

    千次阅读 2012-09-12 09:44:38
    匈牙利命名法 维基百科,自由的百科全书 跳转到: 导航、 搜索 跳过字词转换说明   匈牙利命名法是电脑程序设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法和匈牙利应用命名...
  • 匈牙利命名法是电脑程式设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法和匈牙利应用命名法。原始的匈牙利命名法,现在被称为匈牙利应用命名法,由1972年至1981年在施乐帕洛阿尔托研究中心工作的-...
  • 变量的前缀由三个部分组成:范围修饰,类型修饰,类型前缀。前两部分也许是不适用的。...这个体系包含了很多匈牙利标记优点,并且将很多缺点排了出去,使得整个体系简单,容易。 Type prefix Mean...
  • 代码的两种命名方法:驼峰命名、匈牙利命名优缺点) 一、骆驼命名法:  小驼峰法(camel方法)变量一般用小驼峰法标识。  第一个单词以小写字母开始;第二个单词的首字母大写或每一个单词的首字母都采用大写...
  • 所以这个系统年代比较久远,而且它的数据库表命名方式采用的还是匈牙利命名法,导致在重构时因为这个命名方式恶心了我好久…… 匈牙利命名法 匈牙利命名法(Hungarian notation),由1972年至1981年在施乐帕洛阿尔托...
  • 匈牙利命名法

    2010-09-21 11:57:00
     n年以前,Charles Simonyi(他后来成为微软的著名程序员)设计了一种以前缀为基础的命名方法,这种方法后来称为"匈牙利表示"以记念他.他的思想是根据每个标识符所代表的含义给它一个前缀.微软后来采用了这个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,996
精华内容 798
关键字:

匈牙利命名法的优点