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

  • Abel Avram
  • 马德奎

2013 年 8 月 19 日

话题:语言 & 开发

纽约时报发布了其 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])

不好的做法

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

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

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


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

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

语言 & 开发