高效编写代码的方法(二):常量的定义

简洁语法

正式介绍常量定义前,先介绍一下Objective-C的一些语法糖,完全与常量定义无关,知道的可以跳过。
一般来说,我们定义NSString,NSArray,NSDictionary时,都会直接像下面这样书写:

    NSString *aStr = @"AAAAA";
    NSArray *array = @[@"a",@"b",@"c"];
    NSDictionary *dic = @{
        @"a":@"A",
        @"b":@"B",
        @"c":@"c"
    };

以上就是OC对于这三个类的简洁语法,包括数组的访问,字典的方位都可以使用方括号形式,不再多说。
值得注意的一点是要知道这样的好处在哪里?为什么要这么书写?
1、简洁,可读性高。
2、安全性较高。举个例子:
比如NSArray 的创建,不使用简洁语法情况下我们通常这样来写:

NSArray *bArray = [NSArray arrayWithObjects:aObj,bObj,cObj, nil];

以此创建一个包含三个对象的数组,但是当bObj为nil时,上面那种方式就会带来一个错误:bArray只包含一个元素aObj。因为上面这种方式创建数组,会在遇到空对象(nil)时就结束了对后面元素的获取。
你希望自己的数组元素不可控,还是希望能在有隐患时能够有个明显报错?
如果希望后者,建议使用简洁语法。这样bObj为空时,编译期间就会报错。
这点对于字典也是相同的。

正题:常量的定义

通常为了提高维护性或者阅读方便,我们会引入常量。
通常,常量的方式有两种:
一种是使用#define 预处理宏,第二种是使用static const。

有两个问题:
那么到底哪种方式比较适合?
常量怎么书写?

问题一

通常来说,static const定义的方式会比#define要好一些。
举个例子:
比如在定义动画时间时我们会使用#define ANIMATION_DURATION 0.3f这样的预处理命令,但是这样:
1、丢失了类型信息
2、如果在头文件中#define,容易造成重名,更严重造成“常量”被修改。
比如我在ViewControllerA中#define DURATION 0.3f,
ViewControllerB中又重新#define DURATION 0.5f,
VIewControllerB中又#import了ViewControllerA.h,
此时编译器虽然会警告你DURATION redifined,但是实际上DURATION已经被修改了。

因此建议使用如下方式:

static NSTimeInterval const kAnimationDuration = 0.3;

这样我们即明确了常量的类型,也不会造成会重名修改的问题,因为以上方式的作用域只在该类的.h 和.m下,并且修改就会出现编译期间的错误。

问题二

首先是位置问题,基本所有常量(除全局),我们都应该写在.m文件中。
第一,为了防止重命名,即使是添加了static const关键字的常量,也不能写在.h中。
第二,除了全局变量,我们的常量在.h中存在几乎是没有任何作用的。考虑到封装,我们应该写在.m文件中。

命名问题:

在常量前添加小写字母“k”可以提高代码可读性。如果实在是需要写在头文件中对外界暴露,那么通常我们还需要在常量名前添加一个类名前缀。

static 和const

在声明时,这两个缺一不可,const表示后面的东西是固定的,不可修改的(包括指针)。 因此在声明的时候我们应该把const 放到变量名的前面:比如

static NSSting *const aStr = @"someString";

static表示静态,意味着只有在定义的作用域中才可以使用,在类中声明,该类都可以使用,在方法内部定义,只有在方法内部才能使用。
如果没有static,并且有其他作用域也定义了相同名称常量,编译器会报错,linker类的错误,XCode报错很不明显,需要注意。

全局变量

有些时候我们需要定义全局变量,比如我们的通知名称,在所有注册通知的类中,我们只希望知道通知常量名,而不真正关心常量具体内容。声明可以如下:
在.h中:

extern NSString *const FHKeyboardNotification;

在.m中:

NSString *const FHKeyboardNotification = @"keyboardDidChange";

extern关键字作用是用来告诉编译器,记住存在FHKeyboardNotification字符串常量即可,并不需要关心它的具体值。
常量应该只被声明一次,编译器会在碰到FHKeyboardNotification进行正确的处理。

总结

1、尽量避免使用#define预处理命令定义常量,因为它有时候不包含类型信息,并且容易被修改。
2、尽量在.m中书写常量。
3、注意全局变量的命名,需要添加类名前缀。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,923评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,154评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,775评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,960评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,976评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,972评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,893评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,709评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,159评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,400评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,552评论 1 346
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,265评论 5 341
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,876评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,528评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,701评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,552评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,451评论 2 352

推荐阅读更多精彩内容