当前位置：K88软件开发 → 文章中心 → 编程语言 → Objective-C → Objective-C01 → 文章内容
代码组织
减小字体
增大字体由
如此轻盈
创建，
最后一次修改
2016-08-12 代码组织来自 Mattt Thompsoncode organization is a matter of hygiene (代码组织是卫生问题)我们十分赞成这句话。
清晰地组织代码和规范地进行定义, 是你对自己以及其他阅读代码的人的尊重。
利用代码块一个 GCC 非常模糊的特性，
以及 Clang 也有的特性是，
代码块如果在闭合的圆括号内的话，
会返回最后语句的值NSURL *url = ({ NSString *urlString = [NSString stringWithFormat:@"%@/%@", baseURLString, endpoint];
[NSURL URLWithString:urlString];
{
);
这个特性非常适合组织小块的代码，
通常是设置一个类。
他给了读者一个重要的入口并且减少相关干扰，
能让读者聚焦于关键的变量和函数中。
此外，
这个方法有一个优点，
所有的变量都在代码块中，
也就是只在代码块的区域中有效，
这意味着可以减少对其他作用域的命名污染。
PragmaPragma Mark#pragma mark - 是一个在类内部组织代码并且帮助你分组方法实现的好办法。
我们建议使用 #pragma mark - 来分离:不同功能组的方法 protocols 的实现对父类方法的重写- (void)dealloc { /* ... */ {
- (instancetype)init { /* ... */ {
#pragma mark - View Lifecycle （View 的生命周期）- (void)viewDidLoad { /* ... */ {
- (void)viewWillAppear:(BOOL)animated { /* ... */ {
- (void)didReceiveMemoryWarning { /* ... */ {
#pragma mark - Custom Accessors （自定义访问器）- (void)setCustomProperty:(id)value { /* ... */ {
- (id)customProperty { /* ... */ {
#pragma mark - IBActions - (IBAction)submitData:(id)sender { /* ... */ {
#pragma mark - Public - (void)publicMethod { /* ... */ {
#pragma mark - Private- (void)zoc_privateMethod { /* ... */ {
#pragma mark - UITableViewDataSource- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { /* ... */ {
#pragma mark - ZOCSuperclass// ... 重载来自 ZOCSuperclass 的方法#pragma mark - NSObject- (NSString *)description { /* ... */ {
上面的标记能明显分离和组织代码。
你还可以用 cmd+Click 来快速跳转到符号定义地方。
但是小心，
即使 paragma mark 是一门手艺，
但是它不是让你类里面方法数量增加的一个理由：类里面有太多方法说明类做了太多事情，
需要考虑重构了。
关于 pragma在 http://raptureinvenice.com/pragmas-arent-just-for-marks 有很好的关于 pragma 的讨论了，
在这边我们再做部分说明。
大多数 iOS 开发者平时并没有和很多编译器选项打交道。
一些选项是对控制严格检查（或者不检查）你的代码或者错误的。
有时候，
你想要用 pragma 直接产生一个异常，
临时打断编译器的行为。
当你使用ARC的时候，
编译器帮你插入了内存管理相关的调用。
但是这样可能产生一些烦人的事情。
比如你使用 NSSelectorFromString 来动态地产生一个 selector 调用的时候，
ARC不知道这个方法是哪个并且不知道应该用那种内存管理方法，
你会被提示 performSelector may cause a leak because its selector is unknown（执行 selector 可能导致泄漏，
因为这个 selector 是未知的）.如果你知道你的代码不会导致内存泄露，
你可以通过加入这些代码忽略这些警告#pragma clang diagnostic push#pragma clang diagnostic ignored "-Warc-performSelector-leaks"[myObj performSelector:mySelector withObject:name];
#pragma clang diagnostic pop注意我们是如何在相关代码上下文中用 pragma 停用 -Warc-performSelector-leaks 检查的。
这确保我们没有全局禁用。
如果全局禁用，
可能会导致错误。
全部的选项可以在 The Clang User'
s Manual 找到并且学习。
忽略没用使用变量的编译警告这对表明你一个定义但是没有使用的变量很有用。
大多数情况下，
你希望移除这些引用来（稍微地）提高性能，
但是有时候你希望保留它们。
为什么？或许它们以后有用，
或者有些特性只是暂时移除。
无论如何，
一个消除这些警告的好方法是用相关语句进行注解，
使用 #pragma unused():- (void)giveMeFive{ NSString *foo;
#pragma unused (foo) return 5;
{
现在你的代码不用任何编译警告了。
注意你的 pragma 需要标记到未定义的变量之下。
明确编译器警告和错误编译器是一个机器人，
它会标记你代码中被 Clang 规则定义为错误的地方。
但是，
你总是比 Clang 更聪明。
通常，
你会发现一些讨厌的代码 会导致这个问题，
而且不论怎么做，
你都解决不了。
你可以这样明确一个错误：- (NSInteger)divide:(NSInteger)dividend by:(NSInteger)divisor{ #error Whoa, buddy, you need to check for zero here! return (dividend / divisor);
{
类似的，
你可以这样标明一个 警告- (float)divide:(float)dividend by:(float)divisor{ #warning Dude, don'
t compare floating point numbers like this! if (divisor != 0.0) { return (dividend / divisor);
{
else { return NAN;
{
{
字符串文档所有重要的方法，
接口，
分类以及协议定义应该有伴随的注释来解释它们的用途以及如何使用。
更多的例子可以看 Google 代码风格指南 File and Declaration Comments。
简而言之：有长的和短的两种字符串文档。
短文档适用于单行的文件，
包括注释斜杠。
它适合简短的函数，
特别是（但不仅仅是）非 public 的 API：// Return a user-readable form of a Frobnozz, html-escaped.文本应该用一个动词 ("
return"
) 而不是 "
returns"
这样的描述。
如果描述超出一行，
你应该用长的字符串文档: 一行斜杠和两个星号来开始块文档 (/**, 之后是总结的一句话，
可以用句号、问号或者感叹号结尾，
然后空一行，
在和第一句话对齐写下剩下的注释，
然后用一个 (*/)来结束。
/** This comment serves to demonstrate the format of a docstring. Note that the summary line is always at most one line long, and after the opening block comment, and each line of text is preceded by a single space.*/一个函数必须有一个字符串文档，
除非它符合下面的所有条件：非公开很短显而易见字符串文档
如此轻盈
创建，
最后一次修改
2016-08-12 代码组织来自 Mattt Thompsoncode organization is a matter of hygiene (代码组织是卫生问题)我们十分赞成这句话。
清晰地组织代码和规范地进行定义, 是你对自己以及其他阅读代码的人的尊重。
利用代码块一个 GCC 非常模糊的特性，
以及 Clang 也有的特性是，
代码块如果在闭合的圆括号内的话，
会返回最后语句的值NSURL *url = ({ NSString *urlString = [NSString stringWithFormat:@"%@/%@", baseURLString, endpoint];
[NSURL URLWithString:urlString];
{
);
这个特性非常适合组织小块的代码，
通常是设置一个类。
他给了读者一个重要的入口并且减少相关干扰，
能让读者聚焦于关键的变量和函数中。
此外，
这个方法有一个优点，
所有的变量都在代码块中，
也就是只在代码块的区域中有效，
这意味着可以减少对其他作用域的命名污染。
PragmaPragma Mark#pragma mark - 是一个在类内部组织代码并且帮助你分组方法实现的好办法。
我们建议使用 #pragma mark - 来分离:不同功能组的方法 protocols 的实现对父类方法的重写- (void)dealloc { /* ... */ {
- (instancetype)init { /* ... */ {
#pragma mark - View Lifecycle （View 的生命周期）- (void)viewDidLoad { /* ... */ {
- (void)viewWillAppear:(BOOL)animated { /* ... */ {
- (void)didReceiveMemoryWarning { /* ... */ {
#pragma mark - Custom Accessors （自定义访问器）- (void)setCustomProperty:(id)value { /* ... */ {
- (id)customProperty { /* ... */ {
#pragma mark - IBActions - (IBAction)submitData:(id)sender { /* ... */ {
#pragma mark - Public - (void)publicMethod { /* ... */ {
#pragma mark - Private- (void)zoc_privateMethod { /* ... */ {
#pragma mark - UITableViewDataSource- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { /* ... */ {
#pragma mark - ZOCSuperclass// ... 重载来自 ZOCSuperclass 的方法#pragma mark - NSObject- (NSString *)description { /* ... */ {
上面的标记能明显分离和组织代码。
你还可以用 cmd+Click 来快速跳转到符号定义地方。
但是小心，
即使 paragma mark 是一门手艺，
但是它不是让你类里面方法数量增加的一个理由：类里面有太多方法说明类做了太多事情，
需要考虑重构了。
关于 pragma在 http://raptureinvenice.com/pragmas-arent-just-for-marks 有很好的关于 pragma 的讨论了，
在这边我们再做部分说明。
大多数 iOS 开发者平时并没有和很多编译器选项打交道。
一些选项是对控制严格检查（或者不检查）你的代码或者错误的。
有时候，
你想要用 pragma 直接产生一个异常，
临时打断编译器的行为。
当你使用ARC的时候，
编译器帮你插入了内存管理相关的调用。
但是这样可能产生一些烦人的事情。
比如你使用 NSSelectorFromString 来动态地产生一个 selector 调用的时候，
ARC不知道这个方法是哪个并且不知道应该用那种内存管理方法，
你会被提示 performSelector may cause a leak because its selector is unknown（执行 selector 可能导致泄漏，
因为这个 selector 是未知的）.如果你知道你的代码不会导致内存泄露，
你可以通过加入这些代码忽略这些警告#pragma clang diagnostic push#pragma clang diagnostic ignored "-Warc-performSelector-leaks"[myObj performSelector:mySelector withObject:name];
#pragma clang diagnostic pop注意我们是如何在相关代码上下文中用 pragma 停用 -Warc-performSelector-leaks 检查的。
这确保我们没有全局禁用。
如果全局禁用，
可能会导致错误。
全部的选项可以在 The Clang User'
s Manual 找到并且学习。
忽略没用使用变量的编译警告这对表明你一个定义但是没有使用的变量很有用。
大多数情况下，
你希望移除这些引用来（稍微地）提高性能，
但是有时候你希望保留它们。
为什么？或许它们以后有用，
或者有些特性只是暂时移除。
无论如何，
一个消除这些警告的好方法是用相关语句进行注解，
使用 #pragma unused():- (void)giveMeFive{ NSString *foo;
#pragma unused (foo) return 5;
{
现在你的代码不用任何编译警告了。
注意你的 pragma 需要标记到未定义的变量之下。
明确编译器警告和错误编译器是一个机器人，
它会标记你代码中被 Clang 规则定义为错误的地方。
但是，
你总是比 Clang 更聪明。
通常，
你会发现一些讨厌的代码 会导致这个问题，
而且不论怎么做，
你都解决不了。
你可以这样明确一个错误：- (NSInteger)divide:(NSInteger)dividend by:(NSInteger)divisor{ #error Whoa, buddy, you need to check for zero here! return (dividend / divisor);
{
类似的，
你可以这样标明一个 警告- (float)divide:(float)dividend by:(float)divisor{ #warning Dude, don'
t compare floating point numbers like this! if (divisor != 0.0) { return (dividend / divisor);
{
else { return NAN;
{
{
字符串文档所有重要的方法，
接口，
分类以及协议定义应该有伴随的注释来解释它们的用途以及如何使用。
更多的例子可以看 Google 代码风格指南 File and Declaration Comments。
简而言之：有长的和短的两种字符串文档。
短文档适用于单行的文件，
包括注释斜杠。
它适合简短的函数，
特别是（但不仅仅是）非 public 的 API：// Return a user-readable form of a Frobnozz, html-escaped.文本应该用一个动词 ("
return"
) 而不是 "
returns"
这样的描述。
如果描述超出一行，
你应该用长的字符串文档: 一行斜杠和两个星号来开始块文档 (/**, 之后是总结的一句话，
可以用句号、问号或者感叹号结尾，
然后空一行，
在和第一句话对齐写下剩下的注释，
然后用一个 (*/)来结束。
/** This comment serves to demonstrate the format of a docstring. Note that the summary line is always at most one line long, and after the opening block comment, and each line of text is preceded by a single space.*/一个函数必须有一个字符串文档，
除非它符合下面的所有条件：非公开很短显而易见字符串文档
代码组织
