MS 的代码中，为啥要这样使用形参？？？

loserwang

其实在 Windows 下最好还是适当地遵循部分写作习惯，不然看起来不伦不类。
但是在面向对象系统的新环境下，我做了少量的改进。

1）改进的匈牙利表示法：

除了匈牙利表示法的建议内容外，包括：

自动变量和部分容器属性以 abcAbcAbc 的形式，但不局限于使用数据类型前缀，可以是 idx, ref, ptr, cnt, val, str, array, list, tls 等等来明确用途。

形参可以不必指定任何前缀，因为类型是其声明的主体，且和自动变量、成员变量区别开来。

成员变量分属性和保护数据，属性和自动变量类似，便于阅读和引用，保护数据则使用 STL 的规范，_AbcAbc。不仅仅是受保护的数据，受保护的成员函数，辅助类一致使用这种格式来“阻止”警示用户。

可以使用下划线，如 _Static_CollisionDetection_Counter，中间一则短语已经头字母大写以示区隔，下划线进一步提升了区隔的等级。

2）函数名一致以 AbcAbc 乃至 Abc_Abc Abc_abc 的方式命名

许多写作者使用 abcAbc 来命名函数，个人认为这种方案不妥的缘由在于它同以上通过匈牙利表示法改进的方案的外观上过于相似，而且与各种 API 的规范也不一致，这使得所有的变量命名不得不写为 abc_abc 的形式，在这类项目上通常可以看到通篇的下划线。

3）不要在函数命名上自做聪明

在这方面最佳的“反面教材”是 D3D Sample Framework。

Set, Get, Query, Clear, Release, Initialize, On, Begin, End, Setup, From, To, Is, Append, Assign, Create, Destroy, Close, Construct, Destruct, Alloc, DeAlloc, Grow, Narrow, Enable, Disable, Pre, After, Retain, Resume, Reset, Attach, Detach 这些前缀在各种模块、类型设计上都会出现，但是 D3D Sample Framework 自己搞了一套，本来是为学习者简化使用难度，且不说非英语国家的用户，即使完全看明白其字面含义，仍要纠缠于其逻辑分类而加重负担。更不用说设计方面的诸多问题了。

这就是我对 Microsoft 的部分代码形式的一些认识。

draculamx

恩。。。。继续学习。。

qrli

FirstSecond的形式叫pascal casing，在java社群里叫upper camel casing
firstSecond的形式叫camel casing，在java社群里叫lower camel casing

微软的代码风格很大程度上受pascal和BSD C风格的影响，而java更多的保留了最早的K&R C风格，由于java前些年的兴起也吸引了很多C++代码采用了java的风格。而纯正的C++更多的保留了unix的小写加或不加下划线的风格，如STL。

现在人们所熟知的匈牙利表示法其实不是真正的，而是被MSDN和样例代码的实习生们错误理解运用，并发扬广大的版本，所以现在微软在极力的推荐不要使用匈牙利表示法。原本的匈牙利表示法起源于微软的office部门，是使用前缀来表示类别而非类型。如rw表示行，cl表示列，x表示像素列，y表示像素行，而这些前缀的数据类型都是整数。