I'm just wondering if @synthesize should still be used even though Xcode does it automatically for properties, simply because it's been done that way for so long? Or does this mean we can all stop using @synthesize (unless you have a reason to give its instance variable a different name)?
I just want to make sure that from a professional standpoint I'm conforming to good coding practice.
除非需要，否则我个人不再将 synthesize 用于新开发 （请参阅下面的 lnafziger 评论）。原因是因为我目前为 iOS 6 开发，这需要新版本的 Xcode，它具有在编译时自动包含的功能。如果我使用旧代码执行此操作，我的组织中可能仍然有人使用旧版本的 Xcode（即 4.2 版），这会给他们带来问题。@synthesize
因此，根据您是否仍需要与旧版本的 Xcode 兼容，这个答案会有所不同。但是如果你只需要使用新版本的 Xcode，你应该可以不声明@synthesize.
直接回答你的问题，我认为，跳过@synthesize并不是不专业的。假设您出于某种原因不需要它（我会谈到这一点），我认为编写更少和更清晰的代码更专业。@synthesize只是噪音。
有几种情况可以考虑：
注意：尽管您可能关心 32 位 OS X，但我什至不确定 Apple 现在是否会接受针对 4.0 之前的 iOS 的应用程序。当然，你真的会限制自己。
@synthesize。（至少有一个案例，与类别有关。）如果你点击这个，@synthesize那个变量并继续前进。不要回去和@synthesize一切。-Weverything您将收到有关此的编译器警告。-Weverything包括所有内容，包括一些建议我认为不明智的更改的警告。这是其中之一。找到适当的警告开关将其关闭（它在警告消息中）并这样做。:)
也可以看看：
If you are ok with your ivar being synthesized with _propertyName you can safely get rid of the synthesize statements. If you want your ivar to be named something else, you need to include it like so
@synthesize propertyName = ________cool_ivar_name
对此确实没有总体正确的答案。除了其他答案给出的特定技术原因（例如将备用 ivar 名称绑定到属性）之外，我认为与您的代码保持一致是最重要的。如果您正在为在@synthesize各地使用的旧库做出贡献，您可能希望以一致性的名义坚持使用它。否则，如果您要重新开始并采用不那么冗长的方法，请@synthesize尽量省略。我个人喜欢不那么冗长的代码，但我更看重代码的一致性，尤其是在清理数千行代码时。