常量的k前缀来自哪里?

Joh*_*ski 32 c c++ objective-c hungarian-notation prefix

常量是以k(例如k_pi)为前缀的常见做法.但这k意味着什么?

它只是c已经意味着char什么?

Mik*_*our 72

这是一个历史上的奇怪现象,在喜欢盲目应用他们不理解的编码标准的团队中仍然是常见的做法.

很久以前,大多数商业编程语言都是弱类型的; 自动类型检查,我们现在认为理所当然,仍然主要是一个学术主题.这意味着很容易编写带有类别错误的代码; 它会编译运行,但却以难以诊断的方式出错.为了减少这些错误,一个名为Simonyi的小组建议您使用标签开始每个变量名称以指示其(概念)类型,以便更容易发现它们何时被滥用.由于他是匈牙利人,这种做法被称为"匈牙利符号".

一段时间后,随着打字语言(特别是C)越来越受欢迎,一些白痴听说这是一个好主意,但不明白其目的.他们建议为每个变量添加冗余标记,以指示其声明的类型.它们的唯一用途是更容易检查变量的类型; 除非有人更改了类型并忘记更新标签,否则他们会有积极的伤害.

第二种(无用的)形式更容易描述和执行,因此被许多团队盲目采用; 几十年后,你仍然不时地看到它被使用,甚至是提倡.

"c"是"char"类型的标记,因此它也不能用于"const"; 所以选择"k",因为这是德语中"konstant"的第一个字母,并被广泛用于数学中的常数.

  • 如果你删除主观和议论部分,我可以接受这个答案;) (8认同)
  • 所以你说谷歌的每个人都是天才? (4认同)
  • 你能提一下这个故事吗?这根本不是我所知道的故事.我知道他们的故事是匈牙利的记谱法被广泛滥用,特别是在微软.特殊的前缀或后缀字符旨在以团队理解的简洁方式提供有关数据的额外信息.静态类型从未打算成为它的一部分.今天,人们(我自己)仍然通常在成员数据名称后附加下划线.这也是匈牙利的表示法. (2认同)
  • @wilhelmtell:在 http://en.wikipedia.org/wiki/Hungarian_notation 上有一个合理的解释,Simonyi 的关于“Apps Hungarian”(第一个变体)的论文可以在 http://msdn2 上找到。 microsoft.com/en-us/library/aa260976(VS.60).aspx。我找不到“Systems Hungarian”(无用的变体)的任何明确说明;正如你所说,这起源于微软,当他们认为这不是一个好主意时,它可能就从历史中消失了。 (2认同)
  • 乔尔·斯波尔斯基(Joel Spolsky)的[使代码看起来不正确](https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/)文章有趣地(像往常一样)描述了Apps匈牙利语和系统匈牙利语。 (2认同)

mis*_*_mp 22

我没有看到那么多,但也许它来自某些语言(特别是德国语言)拼写单词constant - konstant.

  • +1:起源是AFAIK,德国数学家. (3认同)

awm*_*awm 6

这意味着该值是 k 常数。

  • @doron:我认为 c 代表“char”。但话又说回来,它也可以用于 *c*ontainer、排序规则、集合、通用。避免这种风格的另一个原因。 (6认同)
  • 同意...但是常量拼写为 c,那么为什么不拼写为 c呢? (3认同)

she*_*pez 5

我认为数学惯例是先例。k 在数学中一直用作一些常数。


Zac*_*and 5

不要使用匈牙利表示法。如果您想让常量脱颖而出,请将它们全部大写。

附带说明一下:Google编码标准中有很多东西都是不好的做法(就代码的可读性而言)。这是由委员会设计编码标准时发生的情况。

  • 可以说,全部大写只是匈牙利表示法的一种略有不同的形式。两者都只是传达语义意义的约定。 (6认同)
  • “不要使用匈牙利表示法,因为它的命名约定是任意的,而是使用这个任意命名约定!” 这是我得到的氛围。尼克·福吉是对的。使用新手程序员作为例子甚至是无效的。因为他们会问为什么变量的命名全部大写。如果您需要向他们解释。然后解释为什么某些变量以“k”为前缀也没有什么不同。反对匈牙利表示法的唯一有效论据是在其前面加上 u32 或 f64 等类型的前缀。 (4认同)
  • 匈牙利表示法是在变量名(在极端情况下,类名和方法名)前面加上其类型缩写的做法。全部大写可以保持代码的可读性,而不会导致新手程序员问“为什么‘k’在那里?”。所以不,不能说它是匈牙利表示法的“不同形式”。 (3认同)
  • 所有大写字母的问题在于,通常很难阅读,所以研究称。 (2认同)