Swift 3函数命名规则

7

我对Swift 3中的函数命名规范有些困惑。

我查看了Swift 3指南,发现方法命名规范应该如下:

func move(from start: Point, to end: Point)
x.move(from: x, to: y)

但是...

如果我查看UINavigationController的方法,我会找到pushViewControllerpresentViewController方法。这些方法的调用看起来像这样:

navigationController?.pushViewController(viewController, animated: true)
navigationController?.present(controller, animated: true)

现在我在思考为什么pushViewController方法调用不是Swift3的风格。同时,这两个方法之间存在着一定的不一致性。根据指南,我认为push方法应该像这样:

rootNavigationController?.push(viewController, animated: true)

那么它将更像Swift 3。

让我们考虑一个简单的例子:

//1
func saveName(_ name : String) {}
saveName("John")

//2
func save(_ name: String){}
save("John")

//3
func save(name: String){}
save(name: "John")

在我看来,选项3最符合Swift 3指南。但另一方面,由于我的pushViewControllerpresent(controller)方法示例,选项1也不错。
所以我的问题是:哪个选项最符合Swift 3指南?
更新:由于@Sweeper的答案,解决了pushpresent方法之间不一致的原因。
来源:https://github.com/raywenderlich/swift-style-guidehttps://swift.org/documentation/api-design-guidelines/#parameter-names

1
你说了一个魔法词 - 意见。iOS框架早在Swift出现之前就已经编写完成。预计官方Swift指南和现有代码库之间会存在差异。 - Dalija Prasnikar
完全同意,但这些差异会带来一些困惑,这就是我对此有所思考的原因。 - kamwysoc
1
这个有帮助吗?https://stackoverflow.com/questions/40114956/why-isnt-viewwithtag-and-some-other-methods-renamed-in-swift-3 - Sweeper
@Sweeper 是的,这可能解决了为什么 presentpush 方法之间存在不一致的问题。 - kamwysoc
2个回答

7
请看这里:https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md 其中提到:
- 不要从方法的基本名称中删除与封闭类的属性匹配的后缀: 此启发式规则的效果是防止我们为概念上修改类的属性的方法生成过于通用的名称。如果我们放弃“GestureRecognizer”,只保留“add”,那么我们就会得到一个在概念上修改gestureRecognizers属性但使用过于通用名称的方法。
这就是为什么pushViewController没有被重命名。在UINavigationController中,有一个叫做viewControllers的属性。为了避免“过于通用的名称”。
那么为什么present被重命名了呢?
请注意,present是在UIViewController中定义的。UIViewController没有一个叫做viewController或viewControllers的属性,因此ViewController部分被剪切掉了。

3

不一致性:

  • 许多 UIKitFoundation 框架都是用 Objective-C 构建的,并且在 Swift 之前就存在了。
  • 因此,它们有一个 Swift 接口来访问它们,在大多数情况下它们已经尝试匹配,但有时会存在一些不一致性。

目标:

函数是否带外部参数名并不重要。这取决于场景(类、函数和上下文)。

目标是以这样的方式定义函数名称,即仅凭函数名称(无需参数)即可描述函数将执行什么操作。

从使用的角度考虑以及如何调用函数。一个清晰的名称确实可以提高可读性,为良好的设计铺平道路(避免在类 A 或类 B 中混淆函数属于哪一个)。

示例:

struct Record {
    
    var name : String
    var age : Int
    
    func save() {}
}
  • 在这种情况下,可能没有任何参数是有意义的,因为nameageRecord中的属性。

  • 因此,类/结构体/枚举也添加了上下文,因此可以避免不必要/冗余的单词。

  • 具有副作用的函数使用动词表示。

  • 没有副作用的函数使用名词表示。

  • 请参考下面的链接以获取可变和不可变函数。

答案:

因此,它取决于上下文并尝试查看API的使用情况,这将提供更多关于如何设计您的API的见解。

record.save()

注意:以上仅为示例,在您的场景中,save函数可能是不同上下文的一部分。

参考:

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


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接