纽约时报 Objective-C 编码风格指南

纽约时报发布了其 iOS 团队使用的 Objective-C 编码规范，内容涵盖源代码布局、条件表达式编写、变量名、方法和布尔值使用等方面。

纽约时报向来以严谨的写作风格而闻名。数十年前印刷出版的一本手册对他们的写作风格进行了详细说明，许多记者都把它作为参考。现在，该报社的iOS 团队承担起为在Objective-C 中编程的开发人员编写编码指南的任务。编码指南的灵感来自于苹果公司编写的数个Objective-C 及Cocoa 指南。

编码规范通常涵盖源代码的诸多方面，包括布局- 缩进、空格、花括号的使用、大写及注释风格等。每位开发人员都有自己的编码风格，但是很多时候，当加入一个新团队，就需要遵循特定的规范。虽然有些人可能会拒绝遵循严格的编码指南，但是为了提高代码的可读性和降低代码维护的难度，通常还是建议开发人员遵循规范。Sun 公司的“ Java 编程语言编码规范：为什么要有编码规范？”支持遵循规范进行编码的做法，原因如下：

• 一款软件的维护成本占软件整个生命周期总成本的 40%-80%。
• 几乎没有软件在整个生命周期中都是由其作者进行维护。
• 编码规范提高了软件的可读性，使工程师可以更迅速、更彻底地读懂新代码。
• 如果开发人员要将源代码作为产品交付，那么他需要保证，该产品跟他创造的任何一款产品相比，都进行了精心地打包，而且同样简洁。。

以下是纽约时报编码规范的部分内容：

空格——不使用 tab 键，而使用 4 个空格。花括号的左半部分与方法或其它元素在同一行，花括号的右半部分单独占一个新行。

好的做法

 
if (user.isHappy) {
// 做一些操作
}
else {
// 做其它操作
}

不好的做法

 
if (user.isHappy) {
// 做一些操作
} else {
// 做其它操作
}

条件语句总是使用花括号来避免错误。

好的做法

 
if (!error) {
   return success;
}

不好的做法

 
if (!error)
   return success;
if (!error) return success;

变量名应该尽可能地具有描述性。要尽可能地使用属性定义代替无修饰的实例变量。

好的做法

 
@interface NYTSection: NSObject
@property (nonatomic) NSString *headline;
@end

不好的做法

 
@interface NYTSection : NSObject {
   NSString *headline;
}

布尔值——在比较时，不使用 nil、NO 或 YES。

好的做法

 
if (!someObject) {
}
if (isAwesome)
if (![someObject boolValue])
{1}

不好的做法

 
if (someObject == nil) {
}
if ([someObject boolValue] == NO)
if (isAwesome == YES) // 永远不要这样做。

纽约时报 Objective-C 编码风格指南还包括一些其它相关元素的规范，包括方法、命名、字面值、注释、常量和单例等。他们希望得到开发人员的反馈。鉴于可能会有人不喜欢这套规范，他们还推荐了其它公司的规范，包括 Google 、 GitHub 、 Adium 、 Sam Soffes 、 CocoaDevCentral 、 Luke Redpath 或者 Marcus Zarra 。

查看英文原文： The New York Times Objective-C Style Guide

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。