>如果框架被称为AEConicalGradient,那么它中的类应该叫做ConicalGradientLayer和ConicalGradientView或者只是Layer和View？
>如果框架被称为AELog,并且它也有类也称为AELog和其他类称为Line的一些委托回调正在使用此Line类型,如果您的代码还具有称为Line的定义类型,那么如何实现此委托,因为添加框架名称为方法签名func didLog(line：AELog.Line)中的前缀将使错误’Line’不是“AELog”的成员类型,实际上它不是(它是AELog框架的一部分,但它不是AELog类的成员里面).
阅读更多
在为Swift 3更新我的几个框架时,我对框架类的正确命名约定有很多第二想法,这取决于框架名称本身.
最后我意识到我并没有在不同的框架中使用相同的约定,所以现在我不喜欢这种缺乏一致性.
我会直接跳到我遇到的一些现实世界的例子中：
示例：框架没有一个名为框架名称的类：
框架命名为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.示例：Framework有一个名为框架名称的类：
框架被命名为AELog,它由3个公共类和一个委托协议组成：
>共享实例(并为其委托)
>日志线模型
>配置
讨论：
a)类似于第一个版本框架中的第一个例子,我有一个名为AELog,AELogDelegate,AELogLine和AELogConfig的类 – 所有内部单个AELog.swift文件.
b)在Swift 3的最新更新中,我结束了多个文件和类名：AELog,Line和Config.
那就是当我意识到如果你导入AELog并实现AELogDelegate(它只有func didLog(line：Line))和你已经有一个不同的Line类在你自己的模块中定义,它会产生一个冲突,只能通过重命名一个那两个班级班！
说实话,我真的不明白如何避免这种情况.因为如果您尝试使用委托方法中的命名空间类型,如func didLog(line：AELog.Line),则会收到错误’Line’不是“AELog”的成员类型,但它不是AELog类的成员).
那就是当我开始感到有点担心这个“松散”的命名.对此具体事项有任何建议或意见？
c)本着在1.c)方法中的非常“松散”命名的精神,可以将AELog类重命名为Log,并将AELogDelegate重命名为Delegate？这个修正错误是否在2.b中说明),因为没有类与框架名称相同,因此编译器会在这种情况下识别AELog.Line？
>类型名称应该是ConicalGradientView和ConicalGradientLayer. “视图”和“层”对于“视图”或“层”概念的情况来说不足以描述.
> Swift编译器不可能在该上下文中消除冲突模块/类型名称的歧义.您不会从Apple或来自第三方的代码中使用与其中的框架/模块vs类型的冲突名称.这可能是出于技术原因,但也会令人困惑,您的“AELog”作为Swift类型名称的情况也不是惯用的.
长的答案
一个类型的名称应该以某种方式使用该类型的程序中的describe its role.虽然这当然是主观的,但我认为“视图”是视图子类的非常描述性的名称,因为有几十个NSView / UIView Cocoa中的子类和视图可以在您自己的应用程序中实现数百个角色.所以,只要通过看到不合格的类型名称,你就不能真正猜测它的作用,所以它不是一个好名字.模块/命名空间名称的功能更多是提供最小的消歧歧义,导致名称冲突的不确定行为(例如传统上不适用于C / Objective-C的奢侈品),但可以说它的作用不是常规使用完全合格的形式.
还从“如果我想在我的框架中引入视图的一个新变体怎么办”呢？ – 一个单独的框架,特别是锥形梯度,例如听起来有点滑稽.一个框架可能是针对不同类型的观点,对它们来说有一个渐变,听起来像是一个更合理的“最小尺寸”的框架(即使你现在只能为您的需要实现一个圆锥形的情况),同样适用于像“层”这样的概念.如果“AEGradientView”是您的框架名称,那么您可以在其中使用诸如ConicalGradientView,RadialGradientView等内容,这样就可以很好地读出.最后,如果您希望在从框架中使用API时更简单,您可以随时使用typealias.
所以,充分描述是一个因素,但当然,简洁是你想平衡的另一个因素.如果你真的真的有一个类型的案例,在框架中真正是独一无二的,类型名称可以简短明确地表明其作用,那么我的惯例至少是使用最简单的可能的名称.因此,例如在我共同设计的特定图像数据和元数据处理框架中,Image是用作图像数据和元数据的容器的类型的名称.因为在这个框架的真正意义上,只有一个“image”角色的类,而且至关重要的是,它清楚地描述了什么是类(例如“View”).以相同的方式,我使用最简单的可能的名称作为嵌套类型,因此例如用于表示“图像错误”(符合Swift.Error的枚举)的类型称为Carpaccio.Image.Error.
关于您关于模块/类型名称冲突的第二个问题,这种模糊性无法在编译器的情况下解决.你也确实不会发现模块和类型名称的任何实例在任何苹果的框架中变得困惑(我也不会想到在第三方代码中遇到过这样的例子).除了技术原因,编译器很可能没有办法在模块和冲突类名称之间消除歧义,对于遵循平台约定的程序员也是混乱：将模块名称视为“产品”的名称和类型内部作为组成部分 – 而AELog是Swift中记录框架的好名称,它不会是Swift代码中的一种惯用名称,像“AE”这样的名称前缀在Swift类型中不会被使用 – 它们甚至不需要您在Swift中使用的Objective-C子类,因为Objective-C运行时所看到的类的完全限定名称实际上包含模块名称作为前缀.
今年早些时候也有一个很好的WWDC谈话在Swift API naming considerations,讨论了上面提到的一些.
