我的编码团队已选择实施一个使用@ property的编码标准用于所有实例ivars。对于公开的事物,我们当然在我们的.h文件中定义它们,但对于我们的私有事物,我们在.m文件中在我们的实现上方的接口中定义它们。
self.myvar = whatever
或[self setMyvar:whatever]
,是否重要?它对我来说似乎并不重要,在我们的代码库中似乎有很多混合方式。 答案 0 :(得分:5)
self.myvar = whatever
是
的语法糖[self setMyvar:whatever]
他们完全是一回事。没有任何区别。
答案 1 :(得分:5)
正如其他人所指出的那样,foo.bar
和[foo bar]
是等价的(除了对前者的额外类型要求,但这是次要的。)
FWIW,我们的团队决定完全避开点语法。动机是避免歧义;消息发送总是看起来像消息发送,而.s总是用来访问结构成员。
我们还限制使用@{}
和@[]
来仅创建集合。所有访问都是通过indexOfObject:
,objectForKey:
等完成的。
同样,除了ObjC和C ++之间的几个边框文件之外,我们还使用ARC。我们为所有DEBUG版本打开了静态分析器,所有警告都被视为硬错误。我们也开启了几乎所有可行的编译器警告(有一些根本不实用)。
答案 2 :(得分:2)
self.myVar = x实际编译为[self setMyVar:x] ;.没有运行时差异。
然而;为了便于代码可读性,我建议坚持使用一种方案或另一种方案。如果您已经执行了属性,最好将所有内容保留在点表示法中 - 如果没有其他原因,那么因为这样可以更容易地搜索代码。
答案 3 :(得分:2)
有很多类似的问题。
在我们的编码标准中,我们不关心使用点符号或方法来访问属性。我们有时甚至对未正式声明为属性的方法使用点表示法,因为使用库方法有时很难在不检查文档的情况下知道它并且它没有区别。
禁止直接方法调用(难以执行)永远不会有意义 我看到了禁止点符号的编码标准。
一般来说,我倾向于选择点符号,因为它使我能够将分配分成视觉上分离的部分,例如。
self.a = x;
针对
[self setA:x];
第二个似乎对我不太可读,但这是个人品味的问题。
另一方面,有时直接使用该方法更容易,例如当你将对象作为id
时,你必须使用点符号进行强制转换。
我认为混合两者是一个很好的解决方案。选择一个会增加给定地点可读性的那个。