【发布时间】:2016-10-24 22:18:56
【问题描述】:
TLDR
如果框架被称为 AEConicalGradient,那么其中的类应该被称为 ConicalGradientLayer 和 ConicalGradientView 还是只是 Layer 和 查看?
-
如果框架被称为 AELog,并且它有一个类也称为 AELog 和其他类称为 Line 有一些委托回调正在使用此 Line 类型,如果您的代码还定义了名为 Line 的类型,如何实现此委托,因为在方法签名
李>func didLog(line: AELog.Line)中添加框架名称作为前缀将使错误'Line' is not a member type of 'AELog'实际上不是(它是 AELog 框架 的一部分,但它不是其中的 AELog 类 的成员)。
了解详情
在为 Swift 3 更新我的几个框架时,根据框架名称本身,我对框架类的正确命名约定有很多想法。
最后我意识到我并没有真正在不同的框架中使用相同的约定,所以现在我不喜欢这种缺乏一致性的情况。
我会直接跳到我遇到的一些现实世界的例子:
1.示例:框架没有名为框架名称的类:
框架名为 AEConicalGradient,它由 2 个公共类组成:
- CALayer 子类
- UIView 子类
每个类的正确名称应该是什么?
a) AEConicalGradientLayer 和 AEConicalGradientView
b) ConicalGradientLayer 和 ConicalGradientView
c) 图层和视图
讨论:
a) 我在框架的第一个版本中使用了这个,这两个类都在一个 AEConicalGradient.swift 文件中。我不再喜欢这种方法了,我将源分成多个文件,所以现在我在考虑 b) 和 c) 方法之间。
b) 在这种方法中,我喜欢这样一个事实,即有人可以将这些文件拖到项目中(例如,不使用任何依赖项管理器)或复制/粘贴代码,并且不会过多地丢失上下文(因为清楚名称),但另一方面,如果您将其视为 AEConicalGradient.ConicalGradientLayer 和 AEConicalGradient.ConicalGradientView,这听起来有点重复。
c) AEConicalGradient.Layer 和 AEConicalGradient.View 听起来像我想要的方式,但另一方面,这些更有可能如果有人有自己的 Layer 或 View 类,或者如果他们只是拖动文件或复制/粘贴代码上下文几乎丢失了(比如这是什么Layer 或 View 类?)。
2。示例:框架确实有一个名为框架名称的类:
框架名为 AELog,它由 3 个公共类和一个委托协议组成:
- 共享实例(及其委托)
- 原木线模型
- 配置
讨论:
a) 类似于第一版框架中的第一个示例,我有名为 AELog、AELogDelegate、AELogLine 和AELogConfig - 全部在单个 AELog.swift 文件中。
b) 在 Swift 3 的最新更新中,我最终得到了多个文件和类名:AELog、AELogDelegate、Line 和 配置。
那时我意识到,如果你 import AELog 并实现 AELogDelegate(它只有 func didLog(line: Line))并且你已经在你自己的模块中定义了一个不同的 Line 类它将使只能通过重命名这两个 Line 类之一来解决的冲突!
说实话,我真的不明白如何避免这种情况。因为如果你尝试在像func didLog(line: AELog.Line) 这样的委托方法中输入命名空间,你会得到错误'Line' is not a member type of 'AELog',实际上它不是(它是AELog 框架 的一部分,但它不是 的成员>AELog 类在里面)。
那时我开始对这种“松散”的命名感到有点担心。对这个具体问题有什么建议或意见吗?
c) 本着 1.c) 方法中非常“松散”的命名精神,是否可以将 AELog 类重命名为 Log 和 AELogDelegate 只是 Delegate?这是否会修复 2.b) 中所述的错误,因为没有与框架名称相同的类,所以在这种情况下编译器可能会识别 AELog.Line?
问题:
这些方法中的任何一种都有哪些“干净的代码”参数?是否有一个明显的“正确”方法应该如何完成?我在这里遗漏了什么重要的东西吗?
【问题讨论】:
-
这应该在这里:swift.org/documentation/api-design-guidelines 还有一些关于包管理器的更多信息,您可能需要考虑这些信息。
-
另外,在类名前加上你的包/库缩写是一个 Objective-C 标准,在 Swift 中是不鼓励的
-
关于 Swift 命名指南的要点。我在回复中添加了指向它的链接。还链接到关于该主题的 WWDC 演讲,这就是我将这些内容充分内化的地方,以便在下面发布我对这个问题的回复(除了阅读大量源代码之外)。
-
我觉得有趣的是,如果没有我对 mz2 响应的支持(我仍然觉得它比我的好),投票结果是 4-3。 Swift 是一种有趣的编程语言!我发现关于 API 的 WWDC 演讲也非常好。命名约定似乎仍然有很多“个人”风格。看看 Swift 5.0 的到来应该会很有趣......
标签: swift frameworks coding-style swift3