美文网首页iOS 笔记
Objective-C编程规范以及建议

Objective-C编程规范以及建议

作者: Dayon | 来源:发表于2017-08-10 14:39 被阅读9次

    方法声明和定义

    -或者+和返回类型之间须使用一个空格,括号要同行并有一个空格

    方法应该像这样:

    - (void)doSomethingWithString:(NSString *)theString {
      ...
    }
    

    如果函数名字太长,可以用冒号对齐,像这样:

    - (void)doSomethingWith:(GTMFoo *)theFoo
                       rect:(NSRect)theRect
                   interval:(float)theInterval {
      ...
    }
    

    当第一个关键字比其它的短时,要保证下一行至少有4个空格的缩进,对齐关键字,像这样:

    - (void)short:(GTMFoo *)theFoo
        longKeyword:(NSRect)theRect
        evenLongerKeyword:(float)theInterval {
      ...
    }
    

    方法调用

    调用时所有参数应该在同一行:

    [myObject doFooWith:arg1 name:arg2 error:arg3];
    

    或者每行一个参数,以冒号对齐:

    [myObject doFooWith:arg1
                   name:arg2
                  error:arg3];
    

    方法定义与方法声明一样,当关键字的长度不足以以冒号对齐时,下一行都要以四个空格进行缩进

    [myObj short:arg1
        longKeyword:arg2
        evenLongerKeyword:arg3];
    

    不要使用下面的缩进风格:

    [myObject doFooWith:arg1 name:arg2  // some lines with >1 arg
                  error:arg3];
    
    [myObject doFooWith:arg1
                   name:arg2 error:arg3];
    
    [myObject doFooWith:arg1
              name:arg2  // aligning keywords instead of colons
              error:arg3];
    

    命名

    对于易维护的代码而言,命名规则非常重要。Objective-C 的方法名往往十分长,但代码块读起来就像散文一样,不需要太多的代码注释
    当编写纯粹的 Objective-C 代码时,我们基本遵守标准的 Objective-C naming rules

    文件名

    扩展名 文件分类
    .h C/C++/Objective-C 的头文件
    .m Objective-C 实现文件
    .mm Ojbective-C++ 的实现文件
    .cc 纯 C++ 的实现文件
    .c 纯C 的实现文件

    类名

    类名(以及类别、协议名)应首字母大写,并以驼峰格式分割单词
    Objective-C 方法名
    方法名应该以小写字母开头,并混合驼峰格式。每个具名参数也应该以小写字母开头方法名应尽量读起来就像句子,这表示你应该选择与方法名连在一起读起来通顺的参数名。(例如,convertPoint:fromRect: 或 replaceCharactersInRange:withString:)。详情参见 Apple’s Guide to Naming Methods
    第二个参数不要and:

    • 正确:- (instancetype)initWithWidth:(float)width :(float)height;

    • 不好:- (id)initWithWidth:(float)width andHeight:(float)height;

    变量名

    应该使用驼峰命名法,变量名尽量能够代表其自身意思,尽量避免中英文混合命名,中英文混合命名是建议用'_'下划线分割中英文。尽量避免如下命名方式

    NSDictionary *d0 = [ACGPCacheCenter readFileAtSubDir: HSHomePageSubDirForAD];
    NSDictionary *d2 = [ACGPCacheCenter readFileAtSubDir: HSHomePageSubDirForZX];
    NSDictionary *d3 = [ACGPCacheCenter readFileAtSubDir: HSHPSubDirForEntry];
    NSDictionary *d4 = [ACGPCacheCenter readFileAtSubDir: HSHPSubDirForCopywriting];
    

    循环以及一些生命周期很短、很浅显易懂的变量可以放开要求,可以使用简单单字母等等变量名

    常量名

    常量名(如宏定义、枚举、静态局部变量等)应该以小写字母 k 开头,使用驼峰格式分隔单词,
    如:kInvalidHandle,kWritePerm

    注释

    建议注释不要过多,尽量能够做到代码自解释。与其给类型及变量起一个晦涩难懂的名字,再为它写注释,不如直接起一个有意义的名字
    关于注释有以下几点建议:

    .h 文件注释

    .h 文件中 interface 前要加Document注释,例如下面这个类,根据类名根本不知道哪个模块,做什么的。

    @interface HSHPCopywritingCell : HSBaseCollectionViewCell
    
    @end
    

    应改成

    /**
     首页模块-自选股cell
     */
    @interface HSHPCopywritingCell : HSBaseCollectionViewCell
    
    @end
    

    之后在业务代码中遇到这个类,按住alt键鼠标点击类名就可以查看到类的Description如下:

    image.png

    属性以及成员变量注释

    属性、成员变量、枚举类型的注释建议用 /**< 注释内容 *////<注释内容 进行注释

    @property (nonatomic, strong) HSMarketIndexModel *USmodel;      /**< 美股指数model */
    @property (nonatomic, strong) HSMarketIndexModel *HKmodel;      /**< 港股指数model */
    @property (nonatomic, strong) HSMarketIndexView *indexView;      /**< 指数view */
    

    同样按住alt键鼠标点击类名也可以查看到类的Description,用/** 美股指数 */ 这种注释方式也可以看到Description,不过属性太多可能会不太美观

    代码块注释

    善用#pragma mark把代码进行分类,#pragma mark没有下划线,#pragma mark -有下划线分割

    建议用如下类似代码块组织代码:

    #pragma mark - ================ LifeCycle =================
    - (void)viewDidLoad {
        [self configUI];
        ...
    }
    - (void) viewWillAppear:(BOOL)animated {
    }...
    
    - (void)configUI {
    }
    
    #pragma mark - ================ Public Methods =================
    
    #pragma mark ==== 核心公开方法注释
    - (void)somePublicMethod {
    }
    
    #pragma mark ==== 核心公开方法注释2
    - (void)somePublicMethod2 {
    }
    
    #pragma mark - ================ Private Methods =================
    
    #pragma mark ==== 核心私有方法注释
    - (void)somePrivateMethod {
    }
    
    #pragma mark - ================ UITableView Delegate =================
    
    - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView { 
    }...
    
    #pragma mark - ================ Actions =================
    
    - (void)someButtonClicked {
    }
    
    #pragma mark - ================ Getter and Setter =================
    
    - (void)setModelArray:(NSMutableArray *)modelArray {
    }
    

    注意:代码块的顺序应该是由重要到不重要,Getter之类的不重要代码块要放在最后,确保别人打开你的类先映入眼帘的是有用的代码


    其他

    保持公共API简单

    如果一个函数压根没必要公开,就不要这么做,属性也是一样,同时对方法进行合理的Document注释,公开属性以及常量、枚举尽可能的用///<注释,除非特别特别简单的可以省略

    关于警告

    代码中遇到警告信息应该尽量解决掉,有一些可能是类型转换警告,有一些是无用的变量,代码永远不会被执行,已废弃的方法等等,有一点代码洁癖、对自己的代码要求严格是一件好事

    关于废弃的代码

    项目中遇到废弃的代码、没有用到的类(头文件)、注释掉的代码,除非一定要保留的都要尽量删掉,保留的写好注释,建议用TODO注释,保留的原因以及相关责任人,以便其他人接手不至于懵逼~

    一些建议

    定义常量时:多用类型常量,少用#define预处理指令

    宏定义没有类型,有被重复定义风险,影响项目编译速度。
    建议用

    static NSString * const kConst = @"Hello";
    static const CGFloat kWidth = 10.0;
    

    代替:

    #define kConst @"Hello"
    #define kWidth 10.0
    

    当定义对外公开的常量的时候,我们一般使用如下定义

    //Test.h
    FOUNDATION_EXPORT NSString * const kClassNameconst;
    //Test.m
    NSString * const kClassNameconst = @"hello";
    

    关于枚举

    推荐使用NS_ENUM和NS_OPTIONS定义

    typedef NS_ENUM(NSInteger,TestEnum) {
        MY_INT_CONST = 12345
    };
    
    typedef NS_OPTIONS(NSInteger, SelectType) {
        SelectA    = 0,
        SelectB    = 1 << 0,
        SelectC    = 1 << 1,
        SelectD    = 1 << 2
    };
    

    在枚举类型的switch语句中不要实现default分支,有一个好处是,当我们给枚举增加成员时,编译器就会提示开发者:switch语句并未处理所有的枚举

    尽量使用简洁字面量语法

    NSArray *animals = @[@"dog", @"pig", @"you"];
    Dictionary *dict = @{@"animal":@"tiger", @"phone":@"iPhone 6"};
    
    NSString *dog = animals[0];
    NSString *iphone = dict[@"phone"];
    

    属性的strong、copy

    定义可变类型时不要用copy修饰,会留下崩溃隐患

    @property (nonatomic, copy) NSMutableArray *mutableArrayOfCopy;   ///< 插入数据时会崩溃
    

    一般NSString 以及NSArray等等不可变类型建议用copy修饰,用strong修饰也没错,不过要确定情景是否真的需要strong

    结尾:

    本文对Objective-C编码粗略规范以及一些浅显建议,欢迎大家一起补充完善,共同交流进步,维护增强项目代码的易读性,易扩展性,健壮性等等~

    相关文章

      网友评论

        本文标题:Objective-C编程规范以及建议

        本文链接:https://www.haomeiwen.com/subject/lmqhrxtx.html