STM32示例中变量名开头的“uw”是啥意思？

Posted 2023-02-19

【中文标题】STM32示例中变量名开头的“uw”是啥意思？

【英文标题】：What does the "uw" mean at the beginning of variable names in STM32 examples?STM32示例中变量名开头的“uw”是什么意思？

【发布时间】：2018-10-08 20:53:05

【问题描述】：

在阅读 STM32 示例代码时，我看到大量以 uw 开头的变量。例如：

static __IO uint32_t uwLsiFreq = 0;
__IO uint32_t uwCaptureNumber = 0;
__IO uint32_t uwPeriodValue = 0;
__IO uint32_t uwMeasurementDone = 0;

每件事背后都有一个意义或一个故事。 uw 在这里是什么意思？

示例来源：STM32Cube_FW_F2_V1.7.0/Projects/STM32F207ZG-Nucleo/Examples/IWDG/IWDG_Example/Src/main.c.Download link --> 点击“STM32CubeF2”旁边的“获取软件”按钮。

【问题讨论】：

可能：“uw”代表某种Hungarian notation中的“无符号字”

【参考方案1】：

好的，我想发布我自己的更完整的答案。感谢@njuffa 在我的问题下方的评论中指出“可能：uw 代表某种Hungarian notation 中的'无符号字'”，感谢@PeterJ_01 的pointing out Stack Overflow 的首席执行官拥有关于此事的一些意见，并感谢@Sigve Kolbeinson 在 PeterJ_01 的回答下的评论中指出 Stack Overflow 的 CEO 的名字是 Joel Spolsky（如链接中所示），他实际上并不讨厌匈牙利符号，而是只是破坏了它的有限和损坏形式 [Systems Hungarian] 获得了一段时间的关注，并为我们提供了实际的link to the article，因此我们可以了解更多信息并自己阅读文章。

1。这是我回答我的问题的结论：

uw 在许多 STM32 示例变量的开头肯定必须在逻辑上表示“无符号字”，在这种情况下，“字”是 32 位。当我阅读代码时，知道这一点会增加很多清晰度，并消除对名称的一些混淆，所以我很高兴知道这一点。

在这种情况下，这是 Systems Hungarian 用法的一种类型，对于具有显式类型的语言（例如 C 和 C++）通常不鼓励使用，因为它是多余的并且几乎没有增加价值。将此与我在下面描述的 Apps Hungarian 进行对比，Joel Spolsky（Stack Overflow 的首席执行官）strongly promotes 是一种帮助“错误代码看起来错误”的方法。

2。以下是我通过他们的 cmets 和他们提供的链接从 @Sigve 和 @njuffa 那里学到的一些额外见解（主要是关于匈牙利符号）：

您可以将本节称为“计算机编程中的匈牙利符号到底是什么？”

Hungarian notation 存在（我之前不知道），是指在每个变量和/或函数名称的开头添加一些额外字符的概念，以提供有关变量或函数的附加信息，例如它的用途，它的类型，或者它的返回类型。 无意中这也回答了我关于 FreeRTOS 命名约定的问题。现在我明白了！他们也使用[主要是系统]匈牙利符号。这里有一些链接。请注意，在第一个链接中，您将看到 FreeRTOS 中所有匈牙利符号用法的列表。这种表示法几乎完全是 Systems Hungarian 表示法，但可以说在指定 文件名 时也使用了一点 Apps Hungarian 表示法，其中在函数或宏名称中定义了函数和宏。 FreeRTOS Hungarian Notation what is v and x means in freeRTOS task creating or used in it? https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html#NamingConventions 匈牙利符号有两种主要形式：Systems Hungarian 和 Apps Hungarian。查看他们的差异here。 Systems Hungarian 本质上是对“匈牙利”符号的原始意图的破坏，该符号的创建者 Charles Simonyi 在他的描述中错误地使用了“类型”一词而不是“种类”（ source)。 Charle 的初衷是将附加信息编码为编程语言本身不固有的变量名。但是，Systems Hungarian 表示法基本上表示将变量的 type 存储到变量名中。例如：unsigned long myVar 现在变为 unsigned long ulMyVar。大多数人似乎认为这是有限的使用或完全没有价值。 Joel Spolksy 不支持这种形式的匈牙利符号as indicated in his article，但他支持 Apps Hungarian 风格。其他意见可以在"Notable opinions" section of the Wikipedia article here中找到。 Apps Hungarian 描述了将附加信息存储到变量名称前面的概念，否则很难推断出这些信息，例如使用 us 表示“unsafe string”和s 表示“安全string”。许多人要么对这种方法感到更中立，要么喜欢并推广它。 Joel Spolsky（Stack Overflow 的首席执行官）和 Steve McConnel 都认为这是一个好主意并推广它的使用。

注意，这是来自Joel's article 的有用摘录：

有人在某处读过 Simonyi 的论文，他在其中使用了“类型”一词，并认为他的意思是类型，就像类，就像在类型系统中一样，就像编译器所做的类型检查一样。他没有。他非常仔细地解释了“类型”这个词的确切含义，但没有帮助。伤害已经造成。

Apps Hungarian 有非常有用且有意义的前缀，例如“ix”表示数组的索引，“c”表示计数，“d”表示两个数字之间的差异（例如“dx”表示“宽度”），等等。

Systems Hungarian 有用处不大的前缀，例如“l”代表 long，“ul”代表“unsigned long”，“dw”代表双字，也就是说，实际上，呃，一个无符号长。在 Systems Hungarian 中，前缀告诉您的唯一信息是变量的实际数据类型。

这是对西蒙尼的意图和做法的微妙但完全的误解......

（强调）

【参考方案2】：

在此命名约定中表示无符号单词。现在几乎不用了。但是有些人喜欢它，因为它向他们展示了变量的类型。其他人讨厌争论这是最糟糕的编程习惯之一（包括 Stack Overflow 的创建者）。 海事组织没关系

【讨论】：

可能值得一提的是，不喜欢通常仅限于将变量名称中的变量类型编码为编码约定，但类型系统未捕获的编码信息被视为更有用（特别是如果经过深思熟虑），详见此处：joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong

您的链接是我在回答中提到的 SO 创建者的意见。 IMO 很麻烦，通常问题来自其他地方。如果编码人员知道他在做什么并且选择的命名约定对他来说更容易，我没有任何反对意见。我反对其中的任何***。 （顺便说一句，许多理论***分子在现实生活中都是可怕的程序员）