IOS 代码书写风格规范

点标记语法

属性和幂等方法(多次调用和一次调用返回的结果相同)使用点标记语法访问,其他的情况使用方括号标记语法。

良好的风格

view.backgroundColor = [UIColor orangeColor];

[UIApplication sharedApplication].delegate;

不良的风格

[view setBackgroundColor:[UIColor orangeColor]];

UIApplication.sharedApplication.delegate;

间距

二元运算符和参数之间需要放置一个空格,一元运算符、强制类型转换和参数之间不放置空格。关键字之后圆括号之前需要放置一个空格。

void *ptr = &value + 10 * 3;

NewType a = (NewType)b;

for (int
i = 0; i < 10; i++)
{

doCoolThings();

}

数组和字典类型的字面值的方括号两边各放置一个空格。

NSArray *theShit = @[
@1, @2, @3
];

字典字面值的键和冒号之间没有空格,冒号和值之间有一个空格。

NSDictionary *keyedShit = @{ GHDidCreateStyleGuide: @YES };

C函数声明中,左括号的前面不保留空格,并且函数名应该像类一样带有命名空间标识。

良好的风格:

void RNCwesomeFunction(BOOL
hasSomeArgs);

长的字面值应被拆分为多行。

良好的风格:

NSArray *theShit = @[

@"Got some long string objects in here.",

[AndSomeModelObjects too],

@"Moar strings."

];

NSDictionary *keyedShit = @{

@"this.key": @"corresponds to this value",

@"otherKey": @"remoteData.payload",

@"some": @"more",

@"JSON": @"keys",

@"and": @"stuff",

};

每一行代码使用4个空格缩进。不使用tab缩进。下图是在Xcode的Preferences进行缩进设置的截图。

方法签名以及其他关键字(if/else/switch/while等)后面跟随的左花括号总是和语句出现于同一行,而右花括号独占一行。

良好的风格:

if (user.isHappy) {

//Do something

}

else {

//Do something else

}

如果一个方法内有多个功能区域,可以使用空行分隔功能区域。

每一行代码不要超过100个字符。

每一个方法之前都有一个99字符宽的注释行,注释行相对于使用空行更能提高代码的辨识度,当一行代码很长的时候,注释行也起到了越界检测的作用。注释行:

///////////////////////////////////////////////////////////////////////////////////////////////////

条件语句

所有的逻辑块必须使用花括号包围,即使条件体只需编写一行代码也必须使用花括号。

良好的风格做法:

if (!error) {

return success;

}

不良的风格:

if (!error)

return success;

或:

if (!error) return success;

三元运算符

长的三元运算符应使用圆括号括起来。三元运算符仅用于赋值和做参数。

Blah *a = (stuff == thing ? foo : bar);

合并的nil三元运算符应该尽量避免。

不良的风格:

Blah *b = thingThatCouldBeNil ?: defaultValue;

多分支条件应该使用if语句或重构为实例变量。

良好的风格:

result = a > b ? x : y;

不良的风格:

result = a > b ? x = c > d ? c : d : y;

异常和错误处理

不要在流控制语句中使用异常(NSException)。

异常仅用于表明程序员的错误。

为了表明一个错误,使用NSError *。

当一个方法通过引用返回一个错误参数,应该检测返回值的状态,而不是错误参数的状态。

良好的风格:

NSError *error;

if (![self trySomethingWithError:&error]) {

// Handle Error

}

不良的风格:

NSError *error;

[self trySomethingWithError:&error];

if (error) {

// Handle Error

}

在方法执行成功的情况下赋值非Null值给错误参数,会使路径跳转到假条件分支(随后程序奔溃)。

代理

除了继承一个类或实现一个协议,否则在头文件中仅使用类声明@class指令,不用#import导入类头文件。

如果一个delegate只有几个方法,比如只是提交和取消,推荐使用block编写动作响应代码。

由于代理方法的声明一般都很长,所以必须将代理对象和其他的协议对象放在实例变量定义的下面,否则实例变量定义的对齐方式将会被打乱掉。

当需要实现多个协议的时候,将每一个协议名拆分到单独的行。

良好的风格:

@interface CustomModelViewController : TTViewController <

TTModelDelegate,

TTURLRequestDelegate

> {

方法

一个方法的命名首先描述返回什么,接着是什么情况下被返回。方法签名中冒号的前面描述传入参数的类型。以下类方法和实例方法命名的格式语法:

[object/class thing+condition];

[object/class thing+input:input];

[object/class thing+identifer:input];

Cocoa命名举例:

realPath    = [path     stringByExpandingTildeInPath];

fullString  = [string   stringByAppendingString:@"Extra
Text"];

object      = [array    objectAtIndex:3];

// 类方法

newString   = [NSString stringWithFormat:@"%f",1.5];

newArray    = [NSArray  arrayWithObject:newString];

良好的自定义方法命名风格:

recipients  = [email    recipientsSortedByLastName];

newEmail    = [CDCEmail emailWithSubjectLine:@"Extra
Text"];

emails      = [mailbox  messagesReceivedAfterDate:yesterdayDate];

当需要获取对象值的另一种类型的时候,方法命名的格式语法如下:

[object adjective+thing];

[object adjective+thing+condition];

[object adjective+thing+input:input];

良好的自定义方法命名风格:

capitalized = [name    capitalizedString];

rate        = [number  floatValue];

newString   = [string  decomposedStringWithCanonicalMapping];

subarray    = [array   subarrayWithRange:segment];

方法签名尽量做到含义明确。

不良的风格:

-sortInfo  // 是返回排序结果还是给info做排序

-refreshTimer  // 返回一个用于刷新的定时器还是刷新定时器

-update  // 更新什么,如何更新

良好的风格:

-currentSortInfo      // "current" 清楚地修饰了名词SortInfo

-refreshDefaultTimer  // refresh是一个动词。

-updateMenuItemTitle  // 一个正在发生的动作

方法类型修饰符+/-后要放置一个空格,各参数名之间也要放置一个空格。

良好的风格:

- (void)setExampleText:(NSString *)text image:(UIImage *)image;

如果方法的命名特别长,将方法名拆分成多行。

良好的风格:

color = [NSColor colorWithCalibratedHue: 0.10

saturation: 0.82

brightness: 0.89

alpha: 1.00];

不要将私有的实例变量和方法声明在头文件中,应将私有变量和方法声明在实现文件的类扩展内。

不良的风格:

//MyViewController.h文件

@interface MyViewController : UIViewController<

UITalbeViewDataSource,

UITableViewDelegate> {

@private:

UITableView *_myTableView;  // 私有实例变量

}

// 内部使用的属性

@property (nonatomic,strong) NSNumber *variableUsedInternally;

- (void)sortName;  // 只用于内部使用的方法

@end

良好的风格:

//MyViewController.m文件使用类扩展

@interface MyViewController()<

UITalbeViewDataSource,

UITableViewDelegate> {

UITableView *_myTableView;

// 外部需要访问的实例变量声明为属性,不需要外部访问的声明为实例变量

NSNumber * variableUsedInternally;

}

// 从Xcode4.3开始,可以不写方法的前置声明,Interface
Builder和Storyboard仍然可以找到方法的定义

@end

构造函数通常应该返回实例类型而不是id类型

参数

方法参数名前一般使用的前缀包括“the”、“an”、“new”。

良好的风格:

- (void)       setTitle:           (NSString *)   aTitle;

- (void)       setName:            (NSString *)   newName;

- (id)         keyForOption:       (CDCOption *)  anOption

- (NSArray *)  emailsForMailbox:   (CDCMailbox *) theMailbox;

- (CDCEmail *) emailForRecipients: (NSArray *)    theRecipients;

变量

变量的命令应尽量做到自描述。除了在for()循环语句中,单字母的变量应该避免使用(如i,j,k等)。一般循环语句的当前对象的命名前缀包括“one”、“a/an”。对于简单的单个对象使用“item”命名。

良好的风格:

for (i = 0; i < count; i++) {

oneObject = [allObjects objectAtIndex:
i];

NSLog (@"oneObject: %@", oneObject);

}

NSEnumerator *e = [allObjects objectEnumerator];

id item;

while (item =
[e nextObject])

NSLog (@"item: %@", item);

指针变量的星号指示符应该紧靠变量,比如NSString *text,而不是NSString* text或NSString * text。

尽量的使用属性而非实例变量。除了在初始化方法(init,initWithCoder:等)、dealloc方法以及自定义setter与getter方法中访问属性合成的实例变量,其他的情况使用属性进行访问。

良好的风格:

@interface RNCSection: NSObject

@property (nonatomic) NSString *headline;

@end

不良的风格:

@interface RNCSection : NSObject {

NSString *headline;

}

当你使用@synthesize指令时,编译器会自动为你创建一个下划线_开头的的实例变量,所以不需要同时声明实例变量和属性。

不良的风格:

@interface RNCSection : NSObject {

NSString *headline;

}

@property (nonatomic) NSString *headline;

@end

良好的风格:

@interface RNCSection: NSObject

@property (nonatomic) NSString *headline;

@end

不要使用@synthesize除非是编译器需要。注意在@protoco协议中的@optional可选属性必须被显式地使用@synthesize指令合成属性。

缩略词

虽然方法命名不应使用缩略词,然而有些缩略词在过去被反复的使用,所以使用这些缩略词能更好的的表达代码的含义。下表列出了Cocoa可接受的缩略词。

........................................................

以下是一些常用的首字母缩略词

ASCII  PDF XML  HTML  URL  RTF  HTTP  TIFF  JPG  PNG  GIF  LZW  ROM  RGB  CMYK  MIDI    FTP

命名

方法和变量的命令应该尽可能做到自描述。

良好的风格:

UIButton *settingsButton;

不良的风格:

UIButton *setBut;

对于NSString、NSArray、NSNumber或BOOL类型,变量的命名一般不需要表明其类型。

良好的风格:

NSString       *accountName;

NSMutableArray *mailboxes;

NSArray        *defaultHeaders;

BOOL             userInputWasUpdated;

不良的风格:

NSString        *accountNameString;

NSMutableArray *mailboxArray;

NSArray        *defaultHeadersArray;

BOOL             userInputWasUpdatedBOOL;

如果变量不是以上基本常用类型,则变量的命名就应该反映出自身的类型。但有时仅需要某些类的一个实例的情况下,那么只需要基于类名进行命名。

NSImage               *previewPaneImage;

NSProgressIndicator  *uploadIndicator;

NSFontManager        *fontManager;      
// 基于类名命名

大部分情况下,NSArray或NSSet类型的变量只需要使用单词复数形式(比如mailboxes),不必在命名中包含“mutable”。如果复数变量不是NSArray或NSSet类型,则需要指定其类型。

良好的风格:

NSDictionary * keyedAccountNames;

NSDictionary * messageDictionary;

NSIndexSet   * selectedMailboxesIndexSet;

由于Objective-C不支持名字空间,为了防止出现命名空间的冲突,在类名和常类型变量名前添加一个由三个大写的字母组成的前缀(如RNC),对于Core Data实体名则可以忽略此规则。如果你子类化了标准的Cocoa类,将前缀和父类名合并是一个很好的做法。如继承UITableView的类可命名为RNCTableView。

常类型变量名的书写风格采用驼峰式大小写(第一个单词的首字母小写,其余单词的第一个字母大写。如firstName而不是first_name或firstname。),并使用关联的类名作为其命名前缀,

推荐的做法:

static const NSTimeInterval RNCArticleViewControllerNavigationFadeAnimationDuration = 0.3;

不推荐的做法:

static const NSTimeInterval fadetime = 1.7;

下划线

使用属性的时候,实例变量应该使用self.进行访问和设值。局部变量的命令不要包含下划线。实例变量的命名必须使用下划线_作为前缀,这样可以缩小Xcode自动完成的选项取值范围。

注释

在需要的时候,注释可对代码做必要的解释。更新代码时一定要更新注释,防止对代码造成误解。

使用javadoc风格的文档注释语法。注释的第一行是对注释API的总结,随后的注释行是对代码更多细节的解释。

良好的风格:

/**

* The maximum size of a download that is allowed.

*

* If a response reports a content length greater than the max * will be cancelled. This is helpful for preventing excessive memory usage.

* Setting this to zero will allow all downloads regardless of size.

*

* @default 150000 bytes

*/

@property (nonatomic) NSUInteger maxContentLength;

init与dealloc

dealloc方法应该被放置在实现方法的顶部,直接在@synthesize或@dynamic语句之后。init方法应该被放置在dealloc方法的下面。

init方法的结构看上去应该像这样:

- (instancetype)init {

self = [super init]; // or call the designated initalizer

if (self) {

// Custom initialization

}

return self;

}

字面值

对于NSString,NSDictionary,NSArray和NSNumber类,当需要创建这些类的不可变实例时,应该使用这些类的字面值表示形式。使用字面值表示的时候nil不需要传入NSArray和NSDictionary中作为字面值。这种语法兼容老的iOS版本,因此可以在iOS5或者更老的版本中使用它。

良好的风格:

NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];

NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};

NSNumber *shouldUseLiterals = @YES;

NSNumber *buildingZIPCode = @10018;

不良的风格:

NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];

NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];

NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];

NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];

如非必要,避免使用特定类型的数字(相较于使用5.3f,应使用5.3)。

CGRect函数

相较于使用结构体辅助函数(如CGRectMake()函数),优先使用C99结构体初始化语法。

CGRect rect = {.origin.x = 3.0, .origin.y = 12.0, .size.width = 15.0, .size.height = 80.0 };

当访问CGRect结构体的x、y、width、height成员时,应使用CGGeometry函数,不直接访问结构体成员。苹果对CGGeometry函数的介绍:

All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications
should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.

良好的风格:

CGRect frame = self.view.frame;

CGFloat x = CGRectGetMinX(frame);

CGFloat y = CGRectGetMinY(frame);

CGFloat width = CGRectGetWidth(frame);

CGFloat height = CGRectGetHeight(frame);

不良的风格:

CGRect frame = self.view.frame;

CGFloat x = frame.origin.x;

CGFloat y = frame.origin.y;

CGFloat width = frame.size.width;

CGFloat height = frame.size.height;

常量

优先使用常类型变量,而不是内嵌的字符串字面值或数字,因为常类型变量能很容易的复用常用的变量值(如π),同时可以快速地修改值而无需查找替换。常类型变量应该声明为static类型,不要使用#define,除非常类型变量被作为宏使用。

良好的风格:

static NSString * const RNCAboutViewControllerCompanyName = @"The New York Times Company";

static const CGFloat RNCImageThumbnailHeight = 50.0;

不良的风格:

#define CompanyName @"The New York Times Company"

#define thumbnailHeight 2

枚举类型

当使用enum关键字时,推荐使用苹果最新引入的固定基础类型语法,因为这将获得强类型检查与代码完成功能。SDK现在包含了一个固定基础类型的宏——NS_ENUM()。

NS_ENUM是在iOS6中开始引入的,为了支持之前的iOS版本,使用简单的内联方法:

#ifndef NS_ENUM

#define NS_ENUM(_type, _name) enum _name : _type _name; enum _name : _type

#endif

良好的风格:

typedef NS_ENUM(NSInteger, RNCAdRequestState) {

RNCAdRequestStateInactive,

RNCAdRequestStateLoading

};

私有属性

私有属性应该被声明在实现文件的类扩展中(即匿名的category)。不要将私有属性声明在命名的category(如RNCPrivate或private),除非是扩展其他类。

良好的风格:

@interface NYTAdvertisement ()

@property (nonatomic, strong) GADBannerView *googleAdView;

@property (nonatomic, strong) ADBannerView *iAdView;

@property (nonatomic, strong) UIWebView *adXWebView;

@end

图片的命名

图片的命名应该保持一致,以图片的用途描述作为图片文件名。文件名的命名使用驼峰式大小写风格,文件名后可跟随一个自定义的类名或者是自定义的属性名(如果有属性名)、也可以再跟上颜色描述以及/或者位置、图片的最终状态。

良好的风格:

RefreshBarButtonItem / [email protected] 和 RefreshBarButtonItemSelected / [email protected]

ArticleNavigationBarWhite / [email protected] 和 ArticleNavigationBarBlackSelected / [email protected]

被用作相似用途的图片应该使用一个图片文件夹进行分开管理。

布尔类型

因为nil被解析为了NO,所以和nil作比较没有任何的必要。不要将变量和YES直接比较,因为YES被定义为1而BOOL类型是8位的unsigned int,即BOOL的值不仅仅是1或0。

良好的风格:

if (!someObject) {

}

不良的风格:

if (someObject == nil) {

}

对于一个BOOL值:两种最佳实践:

if (isAwesome)

if (![someObject boolValue])

不良的风格:

if ([someObject boolValue] == NO)

if (isAwesome == YES) // Never do this.

如果一个BOOL类型的属性名是一个形容词,忽略属性名的“is”前缀是允许的,但需要为访问器指定约定的方法名,比如:

@property (assign, getter=isEditable) BOOL editable;

单例

应该使用线程安全的模式创建共享的单例实例。

+ (instancetype)sharedInstance {

static id sharedInstance = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

sharedInstance = [[self alloc] init];

});

return sharedInstance;

}

附录

Xcode主题

大部分的开发者都使用Xcode默认的字体颜色主题,其实好的主题不仅能提高源代码的辨识度,同时也增添了编码的乐趣。以下是二款Xcode字体颜色主题链接:

https://github.com/vinhnx/Ciapre-Xcode-theme

https://github.com/tursunovic/xcode-themes

代码片段

熟练使用代码片段库可以提高编码的速度。Xcode4中,打开一个项目并让右侧编辑区可视,然后点击右侧底部面板的第四个{}图标,打开代码片段库,你可以将常用的代码拖入其中。以下是一个最新的开源代码片段库链接:

https://github.com/mattt/Xcode-Snippets

时间: 2024-10-26 21:05:31

IOS 代码书写风格规范的相关文章

Java 程序代码书写风格及一些简单的注意事项 (

1. 风格务必保持一贯性(Consistent) 一位同胞顶着我的鼻子问,为什么我们的Java代码缩进格式非得是这样,而不能是他那样,他就是喜欢他自己的这一种,因此他写的代码总是用他自己习惯的风格.结果在Code Review里被大家毙掉,责令修改.因此他是大大地不服.就是风格一贯性问题.其实他的风格,本来也没有什么问题,但在项目里,和其他程序员的程序的风 格,显得扃异,那就存在问题了.比如这个缩进,又比如变量命名方法,不同的类,不同的Methods里,各自不同,这程序就很难看了.所以一旦你选择

3.跟老韩学Python之Python代码书写风格

1.建议初学者尽早习惯Python的缩进规则对于Python而言代码缩进是一种语法,Python没有像其他语言一样采用{}或者begin...end分隔代码块,而是采用代码缩进和冒号来区分代码之间的层次.缩进的空白数量是可变的,但是所有代码块语句必须包含相同的缩进空白数量,这个必须严格执行. #!/usr/bin/env python3 # -*- coding: utf-8 -*- ''' ^--------^-----------^ ProjectName:python-2019 Autho

(转)ios 代码规范

转自http://blog.csdn.net/pjk1129/article/details/45146955 引子 在看下面之前,大家自我检测一下自己写的代码是否规范,代码风格是否过于迥异阅读困难?可以相互阅读同伴的代码,是否存在阅读障碍? 若存在晦涩难懂的,理解成本增大的代码,说明你的团队需要自省了. 下面总结一下OC编程中的一些代码规范(苹果官方推荐的).以OC为示例,但不局限于OC,也可以被当作别的编程语言的开发规范约定(仅需要把OC特有的东西按照你所使用的语言的惯例即可) 参考资料:苹

浅谈Verilog HDL代码编写风格

消失了好久,没有写文章,也没有做笔记,因为最近再赶一个比赛,时间很紧,昨天周六终于结束了,所以趁着周末这会儿有时间,写点东西,记录下来.首先我学习FPGA才一年多,我知道自己没有资格谈论一些比较深层次的问题,对于这个行业来说可能我才是一直脚踩在门外面.所以这篇文章是写给一些刚开始学习FPGA.Verilog HDL的同学,我看过一些大神写的代码,然后尽量模仿大神写法,经过好几个大神的影响和自己的习惯摸索,最终算是总结出了一套自己的代码书写风格,当然我的代码风格还是一直在进化中.现在将自己的一些经

代码书写规范和命名规范

上一篇给大家分享了一下,关于文档编写的几个概念.这篇文章阐述如果编写代码书写规范以及命名规范文档.[以java语言为例] 1.代码书写规范 代码书写规范,能够让不同的人,写出相同风格的代码.很多人都看过java源代码,你会发现java源代码的整体风格几乎是一致的,但是你要知道编写源代码的人是很多的,如何才能让他们写出同一风格的代码呢?这就是代码书写规范的作用. 代码书写规范描述的是如何从头到尾书写代码(自己定义的).通俗点讲就是如何书写java文件.就像你写毕业论文一样,从头到尾每个细节都是有要

iOS代码规范

前言 开发iOS至今已经有一年多的时间了,一直没有对代码做一个比较好的规范,最近公司人手逐渐增多,每个人写的代码都是无花八门,看着十分不习惯.于是综合网上一些人的经验和自己的一些编程习惯,总结出了如下的iOS代码规范. 命名规范 类命名 首字母大写,之后每个单词首字母都大写 使用能够反映类功能的名词短语 文件和类同名 特殊类命名 如果是视图控制器的子类应添加后缀"ViewController"或者"Controller",BeeFramwork中加"Boa

iOS代码规范(Swift 与 OC 混编版)

前言 按照自己的理解整理的 iOS 代码规范,部分规范参考了网上现有的一些资料,希望对大家有所帮助 编码规范 项目结构规范 项目结构图 |-业务1 | |-业务1的Storyboard | |-子业务1 | | |-controller | | |-view | | `-model | |-子业务2 | | |-controller | | |-views | | `-models |-业务2 | |-业务2的Storyboard | |-子业务1 | | |-controller | | |-

前端代码风格规范总结

规范目的:为了提高工作效率,便于后台人员添加功能及前端后期优化维护,输出高质量的文档,在网站建设中,使结构更加清晰,代码简明有序,有一个更好的前端架构. 规范基本准则:符合web标准,使用具有语义的标签,使结构.表现.行为分离,兼容性优良.页面性能优化,代码简洁.明了.有序,尽可能的减少服务器的负载,保证最快的解析速度. 一.文件规范 1.1 HTML部分 1.1.1 建包问题 文件均归档至约定的目录中,建包格式如下: 注意:所有的css文件放在css文件夹中,image放在images文件夹中

PHP PSR-2 代码风格规范 (中文版)

代码风格规范 本篇规范是 PSR-1 基本代码规范的继承与扩展. 本规范希望通过制定一系列规范化PHP代码的规则,以减少在浏览不同作者的代码时,因代码风格的不同而造成不便. 当多名程序员在多个项目中合作时,就需要一个共同的编码规范,而本文中的风格规范源自于多个不同项目代码风格的共同特性,因此,本规范的价值在于我们都遵循这个编码风格,而不是在于它本身. 关键词 "必须"("MUST")."一定不可/一定不能"("MUST NOT"