Swift：全局常量命名规范？

Question

在 Swift 中，全局常量似乎应该使用驼峰命名法。

例如：

let maximumNumberOfLoginAttempts = 10

这是正确的吗？

我习惯使用C语言中的全大写，例如MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS，但我想遵守Swift的约定。

- ma11hew28

---

我也很好奇。如果苹果没有发布Swift命名指南，他们需要尽快发布。 - Sergey Kalinichenko

将宏（不是常量）命名为全大写字母的C语言惯例的原因是，宏是一种特别危险的结构，快速扫描代码以查找宏非常有用，因为在意外情况下进行宏展开通常是导致错误的原因。但我不确定在具有内置支持不可变性的静态类型语言中区分常量和变量的命名惯例是否有任何价值。 - Ferruccio

@Ferruccio，这个约定起源于C语言，但一些后来的语言（如Python、Java）也采用了相同的约定，可能是为了方便从C语言过渡。 - Franklin Yu

Answer 1

根据 Swift 3 API 指南，类型和协议的名称应该使用 UpperCamelCase。其他所有名称都应该使用 lowerCamelCase。

https://swift.org/documentation/api-design-guidelines/

理想情况下，你的全局常量会被放置在某种 enum、extension 或者 struct 内部，该空间的名称应为 UpperCamelCase，其中所有属性的名称应为 lowerCamelCase。

struct LoginConstants {
    static let maxAttempts = 10
}

就像这样访问：

if attempts > LoginConstants.maxAttempts { ...}

(感谢Ryan Maloney的回答，强调了enum的好处)

- bmjohns

---

使用结构体的方法是史诗般的。 - David Seek

Answer 2

我一直在考虑是否在类级别的常量中使用首字母大写的驼峰命名法。例如：

static let MaximumNumberOfLoginAttempts = 10

它仍然是驼峰式命名（似乎是苹果公司推荐的方式），但首字母大写可以清晰地表明该值是不可变的。

- Greg Brown

---

我非常喜欢这个答案，它仍然允许你严格遵循驼峰命名法，同时显示它是一个常量。 - Austin

我最近才意识到，这种方法也与苹果枚举值的命名约定一致（它们也使用带有前导大写字母的驼峰式命名法）。 - Greg Brown

@GregBrown，这已经不再是事实。从Swift 2.2开始，使用lowerCamelCase格式。 - jowie

Answer 3

为了改进bmjohns答案，最好使用枚举而不是结构体作为常量的命名空间。没有情况的枚举无法实例化，而结构体可以。如果它是一个结构体，那么允许通过LoginConstants()实例化它，但这没有意义，也不应该这样做。

惯例是使用枚举进行命名空间，如下所示：

enum LoginConstants {
    static let maxAttempts = 10
}

这样可以确保只有访问其静态成员时才能使用LoginConstants。

- Ryan Maloney

---

好的观点！我修改了我的答案，包括使用全局常量的所有最常见方法，包括枚举。感谢分享！ - bmjohns

@bmjohns 我的意思是，你至少应该在你的编辑中给我点个赞，但是说实话，我认为你应该把它删除，让我们的答案独立竞争。把我的答案复制到你的答案中有点违背投票和优先级系统的初衷。你提交了你的答案，我提交了我的答案，所以我不认为最佳答案应该从得票较少的答案中抄袭所有更好的想法。 - Ryan Maloney

并不是要抢你的风头。真正的问题是命名约定：它们是否应该全部大写，驼峰式，蛇形式等。在我看来，使用枚举，扩展或结构体主要是附加的调味料，这就是为什么我觉得这不算是抢了你的风头。但我确实加了你的署名，一开始没有这样做是我的错。 - bmjohns

Answer 4

我经常看到常量用k来声明，就像这样：

static let kLoginAttemptsMax = value

这也完全遵循驼峰命名法。

- Hobbyist

---

在 Obj-C 的苹果代码中，我经常看到“k”惯例。 - wcochran

这是一项旧的惯例，在Swift中不再使用。 - jowie

"k"用于表示它是某种字典的键，例如JSON实体的名称。 - Derek Argueta

"k"代表“常数”，正如Steve McConnell的书中所述。 - kelin

Answer 5

有几个选项可供选择。

1. 使用苹果的命名约定，如thisIsMyConstant。
   • 优点：由苹果推广，因此是“标准”。
   • 缺点：没有办法在没有Option+Click的情况下区分常量和变量。
   • 附注：苹果并不总是正确的。很多人在苹果做出改变之前就已经使用UIColor.myColor而不是UIColor.MyColor()，包括我。
2. 使用Objective-C风格的kThisIsMyConstant。由于许多Swift开发人员都是objc专家，对大多数Mac/iOS开发人员来说应该很明显。
3. 使用C风格的THIS_IS_MY_CONSTANT。它也被许多其他语言（如Java）使用。
4. 使用类似ThisIsMyConstant的东西。目前我想不起来有哪些语言使用这种风格了（应该有一些，但我只是想不起来），但它与苹果的建议相当接近。

编辑：这也取决于您的linting/autoformatting工具。更多想法已添加为注释。

- superarts.org

---

在我看来，遵循苹果的惯例是正确的选择；它可以使得应用程序更加一致。 - Zorayr

除了 let foo = "bar" 之外，还有更多的选项。例如，对于有限的范围，可以使用 private struct Const；对于共享常量，甚至可以将常量作为依赖项注入。通过使用这些方法，可以减少使用苹果标准时的缺点。 - superarts.org

Answer 6

苹果公司提倡骆驼拼写法（camelCase）。尽管如此，许多人使用下划线加骆驼拼写法（_camelCase），这样做是为了区分它，特别是当您可能具有较低范围的相同名称时。

- Tokuriku

Answer 7

苹果公司使用驼峰式命名法来展示常量。

我使用更易读的变体。因此，对于您的示例：

let maximumNumberOfLoginAttempts = 10
let MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS = 10

“MAXIMUM_NUMBER_OF_LOGIN_ATTEMPTS” 对我来说更易读，并且它立即显示出它是一个常量变量。

- Javatar

---

更易读：否。表示它是一个常量：是。但这并没有提供苹果在 Swift 中最佳实践的答案。 - zaph

苹果公司的最佳实践是使用驼峰命名法。否则，在书中他们会使用'caps-style'（或者我还没有看到）。但在这种非关键性问题上，我会遵循我的直觉-我也不必担心上下文切换错误，比如java<>swift。但这只是我的想法。有些人可能有不同的看法。 - Javatar

我更倾向于首先遵循苹果的约定，或者在工作中参与到工作组的约定之中，亦或者贡献给开源项目。在后一种情况下，我可能会尽力推动采用苹果的约定，因为他们正在制定标准，尽管我能理解@Javatar的建议（顺便说一下，你的名字起得很好）。 - rholmes