Objective-C编码规范

ObjectiveC程序设计规范讯盟产品一部爱城市iOS组陈文经大纲为什么需要程序设计规范objectiveC程序设计规范参考文献为什么需要程序设计规范一份代码的典型的生命周期创建生成维护修改重构或者抛弃团队合作需要代码并不只写给计算机运行的，更重的是，代码是写给程序员看的。包括自己和维护这份代码的程序员。减少编码错误代码规范中包含了很多优秀的代码编写实践。这些实践中包含了很多避免错误的方法。eg：if(true==printerReady){...}一个程序员成长最好的方法就是不断的写代码和阅读好的开源的代码。ObjectiveC程序设计规范代码命名基础空格与注释前缀变量命名规范方法命名规范类与协议命名规范代码命名基础一般性原则:清晰最好是既清晰又尽可能地简短,但不要为了追求简短而丧失清晰性。代码命名基础一般性原则:清晰通常情况下,请不要缩写事物的名称,即使名称很长,也应该把它完全拼写出来代码命名基础一般性原则:清晰▪不过,有一些缩写确实很常见并且有很长的使用历史。因此,您可以继续使用。请参看“可以接受的缩略名称”一节以了解更多的信息。▪要防止API的名称出现歧义。这里的歧义是指名称具有多种解释方式代码命名基础一般性原则:一致性▪请尽可能在Cocoa编程接口中保持名称一致性。如果不太有把握做到这一点,则请浏览一下头文件和参考文档中的范例。▪如果类方法利用多态,一致性就显得尤其重要。因为在这种情况下,不同类用于完成同样事件的方法必须具有相同的名称。代码命名基础一般性原则:无须重复说明空格与注释空格与制表符我们使用空格进行缩进。不要在代码中使用制表符。你应该将你的文本编辑器设置成自动将制表符替换成空格。总结:只使用空格,每次缩进两个空格。行宽即使Objective-C比C++更加冗长,为了保证本指南的可操作性,我们决定保持每行宽度为80列。这比你想的要简单。我们意识到这条规则是有争议的,但很多已经存在的代码坚持了本规则,因此我们觉得保证一致性更重要。通过设置XcodePreferencesTextEditingShowpageguide,来使越界更容易被发现。总结:代码中的每行最多有80个字符。注释尽量注释很重要,但最好的代码应该自解释的。与其给类型及变量起一个晦涩难懂的名字,再为它写注释,不如直接起一个有意义的名字。在修改代码的时候也需要及时更新注释注释文件注释版权信息及作者每个文件应该按顺序包括如下内容:版权信息声明(如:Copyright2008GoogleInc.)授权样版。选择一个合适的项目所使用的授权样板(例如,Apache2.0,BSD,LGPL,GPL)。如果你对其他人的原始代码作出重大的修改,请把你的名字添加到作者里面。当另外一个代码贡献者对文件有问题时,他需要知道怎么联系你,这十分有用。总结:以版权信息作为文件头部,开始每一个文件,后接文件内容的描述。注释声明注释//AdelegateforNSApplicationtohandlenotificationsaboutapp//launchandshutdown.Ownedbythemainappcontroller@interfaceMyAppDelegate:NSObject{}@end如果你已经在文件头部详细描述了接口,可以直接说明“完整的描述请参见文件头部”,但是一定要有这部分注释。另外,公共接口的每个方法,都应该有注释来解释它的作用、参数、返回值以及其它影响。为类的线程安全性作注释,如果有的话。如果类的实例可以被多个线程访问,记得注释多线程条件下的使用规则。总结:每个接口、类别以及协议应该注释,以描述它的目的及作用。前缀ObjectiveC不支持命名空间的概念，所以跟C函数一样，所有的类、常量、函数名都在同一个全局命名空间下。几乎所有的库都会提供前缀。前缀有规定的格式。它需要由两个或者三个大写字符组成,而且不能使用下划线或者“子前缀”。下面是一些例子:在为类,协议,函数,常量以及通过typedef定义的结构命名时,请使用前缀。但在命名方法时,请不要使用前缀,因为方法已经存在于其定义类所创建的名称空间中。同理,在定义结构的字段时,也不要使用前缀。标准前缀标准前缀变量名规范变量名包含以下三类信息变量的用途（它代表什么，index）数据的种类（具名常量，简单变量、用户自定义类型或者类）变量的作用域。（局部变量，类的或者全局作用域。）变量名规范变量名要完全、准确地描述出该变量所代表的事物。currentDate；cd，c，current，date以问题为导向，一个好的名字通常表达的是“什么”（what），而不是“如何”（how）。inputRecord&emplyeeDatabitFlag&printerReady变量名规范合适的变量名长度:2到3个单词，8到20个字符（根据不同的变量权衡）实例变量避免创建公共实例变量。开发人员应该关心对象的接口,而不是对象的数据存储方式这样的细节。请把实例变量显式声明为@private或者@protected。如果您预期所提供的类会被子类化,并且子类可能需要父类的数据,则请使用@protected指令来修饰实例变量。请确保实例变量的名称能够扼要地描述它所保存的属性。如果实例变量将作为类对象的可访问属性,则请务必为其编写存取方法。方法命名方法名称应以小写字符开头,名称中的单词首字符要大写。不要在方法名称中使用前缀。有两种特定的情况不适用该原则。其一,方法的名称可以使用某个众所周知的缩写开头,而该缩写可以大写(例如,TIFF或者PDF)其二,您可以使用前缀来分组并区分私有方法(请参考“私有方法”一节)。如果方法代表一个对象执行的动作,则其名称应该以一个动词开头:方法命名请不要使用“do”或者“does”作为名称的一部分,因为这些辅助性的动词不能为名称增加更多的含义。同时,请不要在动词之前使用副词或者形容词。如果方法返回接收者的某个属性,则以属性名称作为方法名。如果方法没有间接地返回一个或多个值,您也无须使用”get“这样的单词。方法命名所有参数前面都应使用关键字。参数前面的单词应能够对参数进行描述。方法调用方法调用方法调用时,所有参数应该在同一行。;或者每行一个参数,以冒号对齐不要使用下面的缩进风格:类设计规范除非特殊情况，类的大小不要超过500行，如果超过500行，就要将其拆分为2个或者多个类。类的设计原则：单一职责原则类的名称类的名称应包含一个名词,这个名词明确地指示这个类(或者类对象)表示什么或者要做什么。此外,类名称还应该包含适当的前缀。(适应于框架库的设计，请参考“前缀”一节)。Foundation框架以及ApplicationKit框架就有很多这样的例子,例如NSString,NSDate,NSScanner,NSApplication,NSButton,以及NSEvent。类名中的每个单词的首字符应该大写。协议的名称大部分协议会把一些彼此相关但又不合类关联的方法归结在一起,形成一个特殊的方法集合。这种协议要合理地命名,不要将其和类名混淆。一种常见的约定是使用动名词格式(“...ing”):有一些协议会把一些彼此无关的方法归结在一起(不是创建几个独立的小协议)。对于这样的协议,我们倾向于把它和一个类联系起来,利用类来作为协议的主要表现。并且,我们约定让此种协议使用和类一样的名称。NSObject协议就是这种情况。与类相关的委托，例如UITableViewDelegate头文件声明⼀一个独立的类或协议。.如果一个类或协议不属于某个群,则请将其声明放置在一份独立的文件,并使用其名称作为文件名。声明相关联的类或者协议:如果一群声明(类,类别以及协议)彼此相关,则请将它们放在一份文件,并使用主要的类或者协议名称作为文件名。参考文档Cocoa编码指南，CodingGuidelinesforCocoaGoogleObjective-CStyleGuide中文版《代码大全》Thisisnottheend，thisisjustthebeginning.Q&AThankyou!