Objective C - 哪种语法?

发布于 2024-07-30 07:54:39 字数 182 浏览 2 评论 0原文

您认为哪种语法更好/更具可读性?

if(!myViewController.view.superview)

或者:

if(myViewController.view.superview == nil)

谢谢!!

What syntax do you think is better/more readable?

if(!myViewController.view.superview)

or:

if(myViewController.view.superview == nil)

Thanks!!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

帅哥哥的热头脑 2024-08-06 07:54:39

两者非常接近,这取决于个人品味或相关项目的控制标准。

说 !myViewController.view.superview 的意思是“没有超级视图”,这一点非常清楚。

说 myViewController.view.superview == nil 意味着 superview 是 nil 也很清楚。

我可能会更喜欢前者,因为如果我用英语写作,我会说:

如果没有超级视图则

我不会说

如果超级视图什么都没有,那么

但它们是如此接近,并且完全等效,以至于几乎不值得保持一致。 不要误会我的意思,我总体上是为了一致性,只是两者之间的可读性确实没有区别。

The two are very close, it comes down to personal taste or the conding standards of the project in question.

Saying !myViewController.view.superview meaning "no superview" is very clear.

Saying myViewController.view.superview == nil meaning superview is nil is also very clear.

I'd probably favor the former since if I was writing in English, I'd say:

if there is no superview then

I wouldn't say

if the superview is nothing then

But they are so close, and entirely equivalent, that it is hardly worth even being consistent with. Don't get me wrong, I'm all for consistency in general, it is just there really is no difference in readability between the two.

浅语花开 2024-08-06 07:54:39

我使用第二种形式,因为这样意图更明确。

I use the second form because the intention is more clear that way.

远山浅 2024-08-06 07:54:39

以下是 Google Objective C 编码标准的链接:
http://google-styleguide.googlecode.com/svn/trunk/objcguide。 他们没有

明确说明他们更喜欢哪种方式,但他们确实说只使用 nil 进行逻辑检查,上面的示例就符合这种要求。

Here is a link to Google's Objective C coding standards:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

They don't explicitly say which way they prefer but they do say to only use nil for logic checks, of which your example above would qualify.

雪化雨蝶 2024-08-06 07:54:39

就我个人而言,很长一段时间我都使用后一种表达方式,但相反。 使用“foo == nil”(或 nil == foo,以避免由于忘记一个“=”而导致的错误)更加迂腐。 最终你会厌倦输入它,并且第一个版本也不受意外的 nil 赋值错误的影响。

对于新编码员来说,在他们正在编码的内容中保持详细是有好处的,因为它提供了迫使他们思考到底发生了什么的练习,但后来,当然会切换到更快的版本(如果是等效的)。

如果由于某种疯狂的原因,nil 指针不再是 0,而是其他一些无效值(有整个巨大的内存区域作为指针无效),那么使用 '!' 不再起作用,但这永远不会发生(或者如果发生了,他们会添加对编译器的支持以重载“!”,这样在与对象指针一起使用时意味着“无效”并且会做正确的事情无论如何,否则全世界的 Objective-C 开发者都会发疯)。

唯一微妙的问题是,它可能会开始训练您将 C 布尔表达式的值与其他类型的值混淆,因为它们不是同一回事。 因此,如果您开始认为布尔表达式只是一个 BOOL,那么您可能会认为将任何非零值分配给 BOOL 变量就能满足您的要求,但事实并非如此。 由于 BOOL 只是一个 char (当前),如果您执行以下操作:

    - (BOOL)checkFoo {
  BOOL foo = [bar count]; // imagine count is > 255
    if(foo)
      [self doSomething];
    return foo;
}

其中隐式将 256 或更高转换为 BOOL 通过截断得到零(NO),而不是 YES,这就是您想要的,而不是

    - (BOOL)checkFoo {
  BOOL foo = ([bar count] > 0);
    if(foo)
      [self doSomething];
    return foo;
}

- (BOOL)checkFoo {
    if([bar count]) {
      [self doSomething];
      return YES;
    }
    return NO;
}

我所说的全部也就是说,确保您了解背景和微妙之处。

Personally for a long time I used the latter expression, but reversed. Using "foo == nil" (or nil == foo, to avoid bugs caused by forgetting one '=') is more pedantic. Eventually you will get tired of typing it, and the first version is also immune to the accidental nil assignment bug.

It's good for new coders to be verbose in what they're coding, as it provides practise at forcing them to think about what's really going on, but later, of course switch to a version that is faster if it is equivalent.

If for some insane reason, nil pointers were not 0 anymore, but some other invalid value (there's entire gigantic regions of memory which are invalid as pointers), then using '!' wouldn't work anymore, but that will never happen (or if it did, they'd add support to the compiler to overload '!' so that it meant "not invalid" when used with an object pointer and would do the right thing anyway, or else the Objective-C developers of the world would go crazy).

The only subtle problem with this is that it can start to train you to confuse the value of C's boolean expressions with the values of other types, which they aren't the same thing. So, if you start to think a boolean expression is just a BOOL, say, you might assume that assigning any non-zero value to a BOOL variable will do what you want, but it won't. Since a BOOL is just a char (currently), if you do something like:

    - (BOOL)checkFoo {
  BOOL foo = [bar count]; // imagine count is > 255
    if(foo)
      [self doSomething];
    return foo;
}

where implicitly casting 256 or higher to BOOL gets you zero (NO) by truncation, not YES, which is what you want, versus

    - (BOOL)checkFoo {
  BOOL foo = ([bar count] > 0);
    if(foo)
      [self doSomething];
    return foo;
}

or

- (BOOL)checkFoo {
    if([bar count]) {
      [self doSomething];
      return YES;
    }
    return NO;
}

All I'm saying is, make sure you understand the background and the subtleties.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文