Swift实例变量下划线前缀?

时间:2014-06-13 22:41:24

标签: swift

Swift是否删除了实例变量的下划线前缀约定,例如_window?如果是这样,为什么?

7 个答案:

答案 0 :(得分:18)

Apple仍然在其Xcode样板代码中使用_作为non-public变量的约定。你会看到这样的模式:

class Foo {
  var _bar : Bar? = nil
  var  bar : Bar {
    if _bar == nil {
      /* compute some stuff */
      _bar = Bar (/* ... */)
    }
    return _bar!
  }
}

其中对属性的访问是通过bar计算属性进行的。您可以在Apple CoreData 模板中找到它。

答案 1 :(得分:14)

在Objective-C中,当你声明一个属性时@synthesize将自动为clang 3.2创建getter和setter。因此,属性“foo”的默认@synthesize将如下所示:

@synthesize foo = _foo

因为_foo将成为iVar。换句话说,你可以自己完成@synthesize并随意调用iVar:

@synthesize foo = myiVarFoo

所以在这种情况下没有“_”

现在来自the documentation的Swift:

  

Swift将这些概念统一到一个属性声明中。 Swift属性没有相应的实例变量,并且不会直接访问属性的后备存储。

因此从文档中可以清楚地看出,swift没有相应的实例变量,因此不再需要“_”了。

答案 2 :(得分:6)

下划线前缀意味着不要将实例变量_foo与其getter foo混淆。

在快速的情况下,伊娃和吸气剂之间并没有这样的区别。相反,您只拥有属性,因此不需要_约定。

答案 3 :(得分:3)

我说这个_underscoreName约定被删除了(虽然有些Apple模板仍然有它)。

斯威夫特"懒惰的存储属性"使_these不必要。这篇文章:

http://mikebuss.com/2014/06/22/lazy-initialization-swift/

解释得很清楚。

答案 4 :(得分:3)

我使用前导下划线表示私有符号。

是的,下划线最初会妨碍可读性,但在理解和可维护性方面有很大的回报。

e.g:

final class SomeClass
{
    fileprivate let _kMagicNumber: CGFloat = 3.14

    fileprivate struct _PrivateInfo
    {
        let foo: Int
        let bar: String
    }

    fileprivate var _privateInfo: _PrivateInfo

    fileprivate func _setup(with info: _PrivateInfo) { ... }

}

一眼就能看出哪些元素属于哪里。

您不需要点击选项或执行"这是谁属于?"舞。

代码理解不应该依赖于IDE的功能。有时(GitHub,原始文本文件)IDE无法使用。

我理解"它不是惯例"论点。但是约定并没有写在石碑上。 Swift正在迅速发展,我们对它的使用也是如此。

如果Swift团队明天要为私人符号制作注释语法,我就会使用它。但在那之前......

由于我已将我的肥皂盒拿出来,请在您的扩展程序前加上。

请考虑以下代码段:

let color = "#ff7733".hexColor

" hexColor"来自?你自己的代码? Swift标准库?基础? UKit? (哈!)一个CocoaPod?谁知道?

(经验丰富的CocoaPods用户会知道每一个开源库都会实现" hexColor"属性。包含所有需要解决的问题。)

因此,考虑到像#34; Double Secret Probation"这样的公司或项目名称,请考虑使用:

let color = "#ff7733".dsp_hexColor

最后,我强烈推荐这些书和#34;编写固体代码"和#34;代码完成"。

答案 5 :(得分:2)

答案是否定的,因为没有"实例变量"现在在斯威夫特。仅属性(存储属性和计算属性)。

答案 6 :(得分:0)

前缀私有变量的约定早于 ObjCs(奇怪的)属性合成概念的约定。 Clarity 是这种前缀的最初原因,而不是差异化,尽管公开一个没有下划线的 public getter 是有用和常见的......出于显而易见的原因。 IMO,ObjC 道具合成只是在作品中放了一个大胖猴扳手,让每个人都感到困惑......

如果你想要一个私有的综合属性怎么办?为了给你的私有合成属性加上下划线前缀,你需要一个 double 下划线支持变量。 Apple 特别警告不要使用双下划线,这造成了混乱。我们应该费心在内部使用合成属性还是坚持使用支持 var(它仍然有下划线并且显然是私有的)?我们应该停止区分私有变量和公共变量吗?为什么??

在实践中,人们会使用类内部的合成版本作为一种智能设置器,当且仅当他们想要智能时——但这破坏了封装的理想——选择是否使用合成的 setter 需要事先了解幕后发生的事情。

同时,正如上面所指出的,苹果的内部代码仍然使用约定,有时对于合成属性也使用 IIRC。它们仍然适用于 swift 属性!但并非始终如一……您的语言设计政策令人困惑的最大证据是您自己的开发人员没有始终如一地使用它!

清晰是最初的动机,而且效果很好。我说:

带回下划线!

...用于私有变量和方法。权力归于人民!

(P.S. Dart 甚至将其作为一种实际的语言约定来代替 private 关键字!)