匈牙利命名法(Hungarian)

匈牙利命名法解析
本文介绍了匈牙利命名法的基本原则及其两种形式——系统匈牙利命名法和匈牙利应用命名法的区别。详细列举了命名法中的属性和类型前缀,并探讨了其优缺点。

匈牙利命名法是电脑程式设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法和匈牙利应用命名法。原始的匈牙利命名法,现在被称为匈牙利应用命名法,由1972年至1981年在施乐帕洛阿尔托研究中心工作的-程序员查尔斯·西蒙尼(之后任微软总设计师)发明。此命名方法被微软公司广泛推广,以下重点讲述系统匈牙利命名法。

基本原则是:变量名=属性+类型+对象描述,其中每一对象的名称都要求有明确含义,可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。

属性部分举例

序号

全名

属性名前缀

说明

1

global

g_

全局变量

2

const

c_

常量

3

member

m_

C++成员变量

4

static

s_

静态变量

类型部分举例

序号

全名

属性名前缀

说明

1

pointer

p

指针

2

function

fn

函数

3

handle

h

句柄

4

long

l

长整型

5

boolean

b

布尔

6

float

f

浮点型

7

double word

dw

双字

8

string with zero end

sz

字符串

9

short

n

短整型

10

double

d

双精度浮点

11

character

c

字符

12

integer

i

整型

13

real

r

实型

14

un

无符号

综合举例

序号

全名

属性名前缀

说明

1

bBusy

b

布尔

2

pszOwner

psz

指向零结束字符串的指针

系统匈牙利命名法和匈牙利应用命名法的区别

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

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

lAccountNum:变量是一个长整数("l";

arru8NumberList:变量是一个无符号8位整型数组("arru8";

szName:变量是一个零结束字符串("sz"),这是西蒙尼最开始建议的前缀之一。

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

 rwPosition:变量代表一个行("rw")。

 usName:变量代表一个非安全字符串("us"),需要在使用前处理。

 strName:变量代表一个包含名字的字符串("str")但是没有指明这个字符串是如何实现的。

系统匈牙利命名法的优点

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

·拥有类似语义的多个变量可以在一个代码块中使用(例如dwWidthfWidth)。

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

·可以使变量名更加一致。

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

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

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

匈牙利系统命名法的缺点

·匈牙利命名法在编译器做类型检查时是多余的。一个提供类型检查的语言在确定一个变量与其类型一致时,比人眼仅仅检查变量的用法与变量名一致要强大的多。

·一些现代的集成开发环境,如Visual Studio在需要时可以显示变量类型,并且自动标记不匹配的类型。使用这种命名法完全没有必要。

·由于变量名和类型捆绑在一起,因此不利于代码的移植。一个典型的众所周之的例子就是WPARAM类型,以及在许多Windows系统函数声明中使用的wParam参数。它原本是一个16位的类型,但是在后来的操作系统中被改成了32位或64位,但仍保留原来的名字(它实际的基础类型是UINT_PTR,即一个大小足够保存一个指针的无符号整型)。

适用场景

早期程序设计、C++程序设计。


<think>好的,用户之前问过FreeMODBUS代码中的前缀问题,现在他们想了解匈牙利命名法变体。我需要先回忆一下之前是怎么回答的,确保这次回答的一致性。 首先,用户可能对匈牙利命名法有一定的了解,但可能不清楚变体的具体差异。我需要解释标准匈牙利命名法,然后过渡到变体,特别是嵌入式系统中常见的应用。 要确定匈牙利命名法变体的主要特点,比如更强调类型缩写还是用途,或者是否结合了其他命名规则。例如,FreeMODBUS中的前缀如uc、px可能属于变体的一部分,应该举例说明。 用户可能想知道为什么会有变体存在,可能的原因包括简化标准、适应特定领域(如嵌入式系统)的需求,或者提高代码可读性。需要提到这些因素,并结合实际例子。 另外,要确保回答结构清晰,按照用户之前的格式,分点说明,可能用加粗标题和示例代码块。还要注意使用中文,保持口语化,但不要用Markdown格式。 还要考虑用户可能的深层需求,比如他们可能在开发或维护嵌入式系统代码,需要理解现有命名规范以便更好地协作或修改代码。因此,强调变体的实际应用和好处,比如提高可读性和维护性,会更有帮助。 需要检查是否有遗漏的前缀或例子,比如之前提到的us、ul、e、b等,是否需要在此次回答中提及。不过这次问题更关注命名法本身,而不是具体前缀,所以可能不需要详细展开每个例子,但可以举几个典型例子来说明变体的特点。 还要注意区分标准匈牙利命名法和变体之间的差异,例如变体可能更简化,或者结合项目特定的约定,可能不再严格遵循类型系统,而是加入模块或用途的标识。 最后,确保回答符合系统级指令,比如行内公式用$...$,但这里可能用不到数学公式。但需要检查LaTeX语法是否正确,不过用户的问题不涉及数学内容,所以可能不需要。结构上分点,使用标题和示例代码块,但用户要求不要用Markdown,所以可能需要调整,但根据之前的回复,用户允许使用特定格式,比如代码块和加粗。 总结回答结构:先定义匈牙利命名法,然后介绍变体,特点,与标准的区别,嵌入式中的例子,优缺点,以及总结。这样用户能逐步理解变体的来龙去脉和应用场景。</think>--- 匈牙利命名法变体(**Hungarian Notation Variant**)是**一种改进的代码命名规范**,源于经典的匈牙利命名法,但在实际应用中根据领域需求(如嵌入式系统、实时操作系统等)进行了简化或调整。其核心目标是**通过变量/函数名的前缀,快速传递数据类型、作用域或用途等关键信息**,从而提升代码可读性和维护效率。 --- ### 一、**与经典匈牙利命名法的区别** | **特性** | **经典匈牙利命名法** | **变体(嵌入式常见)** | |----------------|-----------------------------|----------------------------| | **核心目标** | 严格标识变量类型(如`i`=int) | **类型 + 用途/模块混合标识** | | **严格性** | 强制要求完整类型标记(如`lpszName`)| **简化前缀,允许自定义规则** | | **典型应用** | Windows API、传统桌面应用 | **嵌入式系统(如FreeMODBUS)、RTOS** | --- ### 二、**变体的核心规则** 1. **前缀标识数据类型** - `uc`: `unsigned char`(无符号字符) - `us`: `unsigned short` - `x`: 自定义类型/模块(如RTOS句柄) - `px`: 指针(`p`) + 扩展类型(`x`,如结构体指针) 2. **用途或模块标识** - `MB_`: Modbus模块相关(如`MB_Init()`) - `v`: 无返回值函数(`void`)或易失性变量(`volatile`) - `e`: 枚举类型(如`eMBError`) 3. **结合领域习惯** - 嵌入式场景中,可能用`HW_`表示硬件相关(如`HW_GPIO_Set()`)。 - RTOS中常用`x`前缀(如FreeRTOS的`xTaskCreate()`)。 --- ### 三、**变体的实际示例** 1. **变量命名** ```c ucRxBuffer[10]; // 无符号字符类型的接收缓冲区 pxFrameData; // 指向协议帧结构体的指针 xTaskHandle; // RTOS任务句柄(自定义类型) ``` 2. **函数命名** ```c vMBPortSerialEnable(); // void函数,启用Modbus串口 eMBPoll(); // 返回枚举类型的Modbus轮询函数 ``` --- ### 四、**变体的优缺点** | **优点** | **缺点** | |------------------------------|------------------------------| | 快速识别类型,减少查文档成本 | 过度简化可能导致歧义(如`x`含义模糊) | | 明确变量用途(如`uc`为寄存器操作) | 需团队统一规则,否则维护困难 | | 适配特定领域需求(如硬件寄存器命名) | 非通用,跨项目学习成本高 | --- ### 五、**适用场景** 1. **嵌入式开发**:资源受限,需快速识别硬件相关变量(如`uc`、`us`)。 2. **RTOS集成**:通过`x`前缀明确任务、队列等系统资源。 3. **协议栈开发**:如FreeMODBUS,用`MB_`标识模块函数。 --- ### 六、**总结** 匈牙利命名法变体是**一种“实用主义”命名规范**,它弱化了严格类型标记,更强调**代码可读性**和**领域适配性**。在嵌入式等特定场景中,它能显著提升协作效率,但需结合团队规则和注释避免歧义。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值