Objective-C：避免 _ 作为局部变量名的技术原因？答案

【问题标题】：Objective-C: technical reasons to avoid _ as a local variable name?Objective-C：避免 _ 作为局部变量名的技术原因？
【发布时间】：2014-05-23 10:35:48
【问题描述】：

在方法（函数、块等）的（可能是嵌套的）范围内考虑这个：

int _ = 42;

是否有任何技术理由来避免使用名为 _ 的局部变量？

一些指导，这个问题的目的：

我知道_ 通常是Objective-C 实例变量的前缀。把它放在一边。欢迎评论与公约的其他冲突。
我也喜欢漂亮的代码，但强烈不鼓励使用品味或纯粹观点的陈述（例如“它{令人困惑、不可读、不可维护}”）在这里†。
我主要想为 Objective-C 回答这个问题，但答案也鼓励与 C 或 C++ 相关的内容。

† 给我买一品脱，你可以告诉我一切。 :)

【问题讨论】：

我看到的唯一缺点是，它不是一个变量的描述性名称，期待它，它是一个有效的 C 变量名称：en.wikibooks.org/wiki/C_Programming/Variables#Naming_Variables
事实上，如果您想成为单行代码和混淆代码（两者同时），这是一个非常好的做法。
我正在寻找技术资料。虽然你们说的可能是很好的做法，但很多编程都是手艺，我仍然认为它们是“品味或纯粹观点的陈述”。
对于谁投票赞成“主要基于意见”的问题：您是否阅读过有关“是否有任何技术原因”和“不鼓励意见陈述”的部分?

标签： c++ objective-c c naming-conventions variable-names

【解决方案1】：

C99 §7.1.3 说，所有以至少一个下划线开头的标识符都保留供实现使用，仅作为文件范围标识符。¹@987654322 @ 是一个至少以下划线开头的标识符，因此您不应该在文件范围内以任何方式定义它。²

然而，作为一个本地变量名，_ 对应用程序程序员来说是公平的游戏。只有以两个下划线或一个下划线加一个大写字母开头的标识符才会被无条件保留。

正如脚注所示，违反这些规则比遵守规则更受尊重。

¹ 是的，这意味着以_ 后跟小写字母开头的“仅供内部使用”函数名称的常见做法在技术上是违反一致性的。

²GNU gettext 是打破此规则的著名第三方库；鼓励程序员将#define _(x) gettext(x) 作为简写。

【讨论】：

谢谢，这正是我正在寻找的信息。我很可能会在一两天内检查你的情况。

【解决方案2】：

简单地回答您的问题 - 不，没有任何技术理由来避免它。不过还有很多其他原因。

【讨论】：

我认为可维护性差是技术原因。
@HotLicks 我编辑了这个问题，专门将可维护性排除在范围之外。