关于手思3.0 代码规范

关于手思3.0 代码规范

工程之始可能需要的工具:

1、使用CocoaPods类库管理工具。CocoaPods安装和使用教程。

2、下载安装注释插件VVDocumenter-Xcode

3.使用代码对齐的Xcode插件

XAlign:XALign

ClangFormat ClangFormat-Xcode

一、手思项目结构管理

#pragma mark -关于手思3.0对于文件的目录要按如下结构创建:
-CategoryEx(所有类别类扩展放在里面)
-HelpMacro(项目宏定义)
-Resources (所有图片资源,声音文件,其他资源,相应资源放入相应组(Group)中)
-Utilities (工具集合,网络请求,工具类,第三方库等)
-MobileSiBuControllers(所有项目模块代码文件)
-CustomUI  (自定义UI控件)
-引用外部文件或者某个单独的功能时,放在单独的组中

关于手思3.0规范要点

1.命名规范(详见下文)
2.所有控制器继承BaseViewController  如:@interface HomeViewController : BaseViewController
3.不能出现警告,过时方法用新方法替代,没有用到的变量删掉或注释掉
4.使用DLOG(<#...#>)打印而不是NSLog(..),有大量打印信息时应把DLOG注释掉
5.使用快捷键Command+shift+B,检查代码内存泄漏问题
6.所有保存数据的实体以Model结尾,如:UserModel
7.viewWillAppear,viewWillDisappear等写在viewDidLoad上面,dealloc写在.m文件最底行

二、编码规范

为了提交团队合作效率,在项目开发中,对于项目、类,变量等的命名,应该要易读,易理解

一)、命名规范

关于命名的一般性的原则

1.最少字符,就是要尽量的减少命名对象的长度,尽量选择字符少的名词

2.名符其实,命名应该能直观的描述被命名对象是什么或者做什么
3.避免歧义,尽量不要采用多义词,也不要使用命名组合之后产生多义的方式
4.上下文一致,比如谓词的统一性,如果都是集合类,那么使用Remove表示删除操作,那么所有上下文就应该都用这个Remove,而不要再用Delete
5.少用缩写,除非是很常见的缩写或者项目中定义好的缩写,否则不要使用缩写
6.优先使用全局常量而非宏,应使用static方式声明常量;

主要点:控制器,自定义view以SB开头
多单词组合时,后面的单词首字母大写
如SBLoginViewCotroller,SBHomeViewCotroller
   SBPopView

(1)类命名

1、变量首字母小写,后面单词首字母大写,如userPassWord

2、使用能够反映类功能的名词短语(使用英文翻译)

3.命名时带上类型,如xxxTv,xxxView,xxxStr等

4、文件名应包含描述继承的类,如:文件名:BaseViewController   类:UIViewController
所有类名,接口名(Protocol)均以大写字母开头,多单词组合时,后面的单词首写字母大写。

如:@interface LoginViewCotroller : UIViewController
View--所有扩展自UIView的类以View结尾,如: GridView,StarView,OpenGLView,EmojiPageView。
ViewController-所有扩展自UIViewController的类以ViewController结尾,
Model--所有数据Model以Model结尾

如 HomePageViewControler, LoginViewController。
如果名称太长则以VC结尾:如 AllPicturePreviewVC

4、自定义控件命名,以相应类名为后缀命名。
对于UI相关的变量,命名时要后缀以特定的控件名,如UILabel的变量命名为xxxLabel,xxxCell,其他的如xxxButton,xxxTableView,xxxImageView等;

常见类型简写如下:
UIViewController:VC    UIImage:Img  UIImageView:Iv
UIView:View  UILabel:Lbl     UIButton:Btn
UINavigationBar:NBar   UIToolBar:TBar  UISearchBar:SBar
UITextField:TF  UITextView:Tv   NSArray:Array
NSMutableArray:MArray    NSDictionary:Dict  NSMutableDictionary:MDict
NSString:Str    NSMutableString:MStr     NSSet:Set       NSMutableSet:MSet

(2)特殊类命名

举例:BaseClient、ImageStore

(3)分类(类别)命名

与类命名相同,此外需添加要扩展的类名和“+”
举例:NSString+URLEncoding

(4)协议(委托)命名

与类命名相同,此外需添加“Delegate”后缀
举例:UITableViewDelegate,MBProgressHUDDelegate

(5)方法及参数命名

方法:

首字母小写,之后每个单词首字母都大写
方法名使用动词短语,能具体表达出该方法的功能

参数:

首字母小写,之后每个单词首字母都大写
具有足够的说明性

举例:

- (void)viewWillAppear:(BOOL)animated
- (void)setupPostValue:(int)value
- (void)adjustFontWithMaxSize:(CGSize)maxSize

参数要用描述该参数的标签命名

- (void) sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;  //对
- (void) sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;               //错

当参数过长时,每个参数占用一行,以冒号对齐。如:

-(void)saveUserInfo:(NSMutableDictionary *)dict
           userName:(NSString *)name
           passWord:(NSString *)pwd{
    ...
}

(6).点击事件响应(下面几种写法都可以)

-(void)loginButtonClicked  (不推荐)
-(void)loginButtonClicked:(id)sender (推荐)
或
-(void)loginButtonAction
-(void)loginButtonAction:(UIButton *)sender
-(void)backBtnAction:(id)sender

手势事件
- (void)handleTapGesture:(UITapGestureRecognizer *)tapGesture

getset 开头的方法有特殊的意义,不要随意定义。

  1. set 是属性默认的设置方法,如果函数不是为了设置类成员,则不要用 set 开头,可用 setup 替代。
  2. get 和属性方法无关,但在 Cocoa 中,其标准行为是通过引用传值,而不是直接返回结果的。欲获取变量,直接以变量名为名,如:userInfomation,而不是 getUserInfomation

属性和变量申明问题

#pragma mark -变量问题
1.私有变量不应该写在h里面,h是对外公开的,更应该写到m里面
2.实例变量(成员变量),最好带上前缀下划线
3.变量需要有一定注释
4.成员变量不应少于3个字符,采取见名知义原则

@interface ViewController ()
{
    //成员变量
    NSString  *_name;     //名字
    int       *_age;      //年龄
    NSString  *_passWord; //密码
    NSArray   *_array1;
}

//属性变量
@property (nonatomic,strong) NSArray *array2;
注意点:私有属性,变量写在.m文件中,.h文件中只写对外公开的属性变量

方法和变量的命令应该尽可能做到自描述。
良好的风格:
UIButton *settingsButton;

不良的风格:
UIButton *setBut;

控件及数据的初始化

#pragma mark -初始化UI控件及数据源
使用initUI(或createSubview) 管理UI控件初始化,initDataSource初始化array,dict
//初始化所有UI相关
- (void)initUI
{
    [self initButton];
    [self initLabel];
}

//初始化数据源
-(void)initDataSource
{
    NSString *dataPath = [[NSBundle mainBundle] pathForResource:@"Data" ofType:@"plist"];
    NSMutableArray  *pesonArray=[[NSMutableArray  alloc]initWithCapacity:0];
}

- (void)initButton
{
    UIButton   *CSButton=[UIButton  buttonWithType:UIButtonTypeCustom];
    CSButton.frame=CGRectMake(100,100, 100, 80);
    [CSButton  addTarget:self action:nil forControlEvents:UIControlEventTouchDown];
    [self.view  addSubview:CSButton];
}

-(void)initLabel
{
    UILabel  *CSLabel=[[UILabel  alloc]initWithFrame:CGRectMake(10, 10, 100, 25)];
    CSLabel.textAlignment=NSTextAlignmentLeft;
    CSLabel.font=[UIFont  systemFontOfSize:14];
    [email protected]"标签";
}

规范示例

#pragma mark ---规范示例 Coding Guidelines for Cocoa--
代码越简洁越明确越好,但是不能因为简洁而导致语义不明确:
代码 	评价
insertObject: atIndex: 	好
insert:at:              不明确,什么被插入?at指什么
removeObjectAtIndex: 	好
removeObject:           好,没有之前讨论的那些问题
remove:                 不明确,什么被移除了

通常,不要缩写对象的名称。即使它们很长,也全拼:
代码 	评价
destinationSelection 	好
destSel                 不明确
setBackgroundColor: 	好
setBkgdColor: 	不明确
--你可能认为某些缩写是众所周知的。但凡是无绝对,尤其是当开发者和你文化、语言背景不一样,看这些缩写就可能产生歧义。
良好的风格:
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];

其他

性能优化
1.用  DLOG(<#...#>)代替 NSLog(...)

2.必要时使用懒加载

3.重用

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

参考资料
[1] 《 NYTimes Objective-C Style Guide 》 https://github.com/NYTimes/objective-c-style-guide
[2]   https://github.com/VincentSit/NYTimes-Objective-C-Style-Guide-ZH (纽约时报 移动团队 Objective-C 规范指南)
[3]   https://github.com/Chinamobo/iOS-Team-Norms (Chinamobo iOS 团队规范)

时间: 2024-11-05 18:39:36

关于手思3.0 代码规范的相关文章

手思3.0 第三方库介绍

手思3.0第三方库介绍 AFNetworking https://github.com/AFNetworking/AFNetworking MBProgressHUD    https://github.com/jdg/MBProgressHUD SVProgressHUD https://github.com/TransitApp/SVProgressHUD SDWebImage   https://github.com/rs/SDWebImage FMDB          https://

四则运算生成器升级版1.0代码规范与测试程序

一.程序设计题目要求和设计思想 1.题目 (1).题目避免重复:    (2).可定制(数量/打印方式):    (3).可以控制下列参数: 是否有乘除法.是否有括号. 数值范围.加减有无负数.除法有无余数.否支持分数 (真分数, 假分数, …).是否支持小数 (精确到多少位).打印中每行的间隔可调整: 2.设计思想 要求1:题目避免重复    设计思想:(1)通过srand(time(NULL));来控制.    要求2:可以定制(数量/打印方式)    设计思想:(1)定义一个参数,利用用户

前端代码规范1.0

意义:该规范旨在统一前端代码书写,规范前端代码标准,为共同协作打下良好基础,提高工作效率. 文件夹/文件命名 图片文件夹:image,images,img Js代码文件夹:js Css文件夹:css 首页:index. 其他页面根据具体情况来定,可以是中文名,英文名,拼音等,以方面认识为主. 页面框架布局 样式名称 样式名称的规则为根据对应位置的英文来命名.如: 头部:header 导航:nav 页尾:footer 消息:news,message 分页:page, 下拉:select 复选框:c

软件工程第二周作业:代码规范和代码复审

0x01 :代码规划的要求 Q:这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反驳) 首先,我们需要明确编码规范的定义,编码规范同时包括了编码风格和其它规范(代码设计上的规范,如设计模式.程序设计.模块之间的逻辑关联等). 编码风格,牵扯到“缩进.空格使用.注释.命名习惯”等多方面的因素,是依致特定编程语言制定的软件工程开发的“约定”,而相同的编码风格,可以使得软件开发过程中轻松浏览任意一段代码,充分保证不同的开发人员能够依据统一的编码格式轻松理解代码的逻

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

最详细的 Swift 代码规范指南

1. 代码格式 1.1 使用四个空格进行缩进. 1.2 每行最多160个字符,这样可以避免一行过长. (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可) 1.3 确保每个文件结尾都有空白行. 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Incl

css代码规范问题重要的有几个

很多人刚开始接触的时候都会遇到很多困难,其中规范的书写格式也较为明显:今天为大家带来一些CSS代码规范的知识. 1.良好的命名规范 ID和class的命名尽可能短,并符合语义.多个单词的拼接用 '-' 符号链接,尽量使用小写字母. 2.代码缩写 CSS代码缩写可以提高你写代码的速度,精简你的代码量. li{font-family:Arial, Helvetica, sans-serif; font-size: 1.2em; line-height: 1.4em; padding-top:5px;

代码规范 for node.js with &#39;npm-coding-style&#39;

npm-coding-style npm's "funny" coding style Description npm's coding style is a bit unconventional. It is not different for difference's sake, but rather a carefully crafted style that is designed to reduce visual clutter and make bugs more appa

iOS代码规范(OC和Swift)

下面说下iOS的代码规范问题,如果大家觉得还不错,可以直接用到项目中,有不同意见 可以在下面讨论下. 相信很多人工作中最烦的就是代码不规范,命名不规范,曾经见过一个VC里有3个按钮被命名为button1.button2.button3,全文没有注释,去看代码逻辑才能知道这三个按钮的意思,我也是醉了! 下面的规范 有的定的比较死,大家可以根据自己团队的风格进行修改.该文章主要是OC的代码规范,有几个是Swift的规范. OC和Swift的代码规范如下: 一.VC生命周期 模块排列顺序 1. 注意