给事物起不明显的名字类似于通过默默无闻的安全性，这在这些部分通常是不受欢迎的。这种安全性的问题不在于它不起作用；确实，它具有一定的价值，这在历史上已被多次证明（例如，这就是为什么坦克被称为“坦克”而不是“装甲战车”）。但是你不能通过默默无闻来量化安全性。您无法知道它为您购买了“多少”安全性；而且，特别是，您根本无法知道它是否有效（尽管它通常运作良好，但也经常失败）。

因此，在考虑风险管理时，非标准名称的价值必须被认为是低的。如果可以“免费”完成，这将不是问题；但非标准名称有巨大的隐藏成本：如果它们迷惑攻击者，他们也可能迷惑系统管理员。它会吸走思考的时间和资源，如果出现问题，还会增加反应延迟。

确实，在 IT 安全和一般 IT 中，描述性名称是必不可少的。

这将是Security Through Obscurity的一个典型例子。虽然这确实提供了一些安全价值，但收益通常非常小，永远不应依赖它作为最终防御。

与任何安全措施一样，如何平衡安全性和可用性是您的组织需要决定的。如果你能想出一个方便的命名约定，对局外人来说是相当模糊的，但对你和你的团队来说很容易学习，这可能是一个值得考虑的问题。如果您经常遇到重大问题，因为人们不记得或无法轻松找到基本服务器或变量名称的列表，那么可能是时候重新考虑此特定解决方案是否适合您.

如果您正在编写一段对安全敏感的代码，那么您应该使用清楚地说明所有敏感信息是什么的名称。

如果一段文本是密码，但您调用它string1，那么在您之后进来的下一个程序员可能会编写没有适当注意变量的代码。

例如，他或她可能会添加一个调试语句，将 的内容吐出string1到日志中，使可以打开调试并访问日志的人可以使用密码。

无论如何，源代码实际上并不包含密码，只有称为密码的变量，除非它非常不安全。没有人会通过查找password源代码中调用的变量来获得任何密码。

为无法识别其功能的服务器选择名称（可能使它们成为黑客更明显的目标）与在程序代码中使用晦涩的名称之间存在很大差异。

您在代码中用于变量的名称不会出现在程序的最终二进制/可执行文件中。这些名称仅存在于您的源代码中。如果有人可以访问源代码，那么晦涩的名称将提供很少的保护。但是，对于那些跟随你的可怜的维护者来说，这真的很不方便。事实上，从长远来看，它甚至可能会降低程序的安全性，因为后来的维护者更有可能误解或误解变量的用途。

编写代码时，第一个也是最重要的目标是正确性。之后是算法和代码意图的交流。使用不能准确反映变量用途的变量名称会减损这一点并使维护变得更加困难。算法将确定您的解决方案的安全性，而不是您为变量使用的名称。