第一话:项目名称命名规则
小驼峰命名法(CamelCase)：第一个单词小写字母开头，其他单词首字母大写；
大驼峰命名法(PascalCase): 所有首字母大写。
命名规范：
1、类名、协议名：遵循大驼峰命名法；
2、常量：这里的常量指的是宏(#define)、枚举(enum)、常量(const)等，使用小写”k“作为前缀，名称遵循大驼峰命名法。
3、方法
* 方法名和方法参数遵循相同的规则，使用小写开头的小驼峰法；
* 方法名和参数尽量读起来像是一句话；
* 方法名不允许使用“get“前缀；
* -或+与返回类型间留一个空格，但参数列表之间不要留间隔；
* 如果参数过多，推荐每个参数各占一行；
4、变量：
类成员变量，属性，局部变量，使用小写开头的小驼峰法，其中类成员变量在名称最后加一个下划线，
比如:myLovalVariable, myInstanceVariable_ ；变量名的名称尽量可以推测其用途，具有描述性。
书写规范：
1. 在m文件中对当前类属性进行引用的时候，使用self.property的方式，用以区分局部变量；对属性进行赋值的时候使用“点”赋值，即A.property = value;
2. 使用import引用头文件的工作全部放到 .h 文件中进行，m文件只保持对当前类头文件的引用；
3. 如果m文件中有较多的method，使用 #pragma mark 标记对方法进行分组，便于查看
第二话:ios项目icon和default图片命名规则
一、应用图片
标准iOS控件里的图片资源，苹果已经做了相应的升级，我们需要操心的是应用自己的图片资源。就像当初为了支持iPhone 4而制作的@2x高分辨率版本（译者：以下简称高分）图片一样，我们要为iPad应用中的图片制作对应的高分版本。我知道不少开发者很有预见性的早在iOS 5.0 SDK上就完成了这一步升级。可是我还是要强调一点，那就是之前 Michael Jurewitz (@Jury)在推上提到过的：
— 如果想让你的高分图片显示在新iPad上，你必须用Xcode 4.3.1 连同iOS 5.1 SDK编译！
二、应用图标
接下来肯定就是为应用主图标制作高分版本了，因为低分版的图标在新iPad桌面上看起来会惨不忍睹。为了支持更多的iOS设备、更高分辨率的屏幕，iOS开发者需要为自己的应用准备各种尺寸的主程序图标文件，而且这个文件列表貌似会越来越长越来越长……（译者：叹气～）。详情请参考最新的苹果开发者文档 iOS App Programming Guide 和 iOS Human Interface Guidelines 。从官方文档中，我找出来针对新iPad的Retina显示屏我们需要准备的东西：
iPad主应用图标 (144×144像素)：之前用在iPad 1、2代上的是72×72 像素。现在我们需要额外的@2x版本（144×144 像素）。
iPad搜索结果图标 (100×100像素)：这个图标出现在系统搜索结果中（译者注：还有在系统设置中，如果应用支持的话）。之前版本用的是50×50像素，现在@2x版本需要100×100像素。
文件命名和Info.plist文件：
根据你的应用需要支持的iOS最低版本不同，你可能需要在Info.plist文件中指定图标文件名，或者是按照苹果的规范命名不同版本的主图标文件。最悲催的情况恐怕就是，你搞的是一个即可跑在iPhone也可跑在iPad上的通用应用（universal app），并且你打算支持iOS 3.1.x甚至更早的版本（译者：其实现在iOS 4.0及以上版本的设备普及率已经很高了，完全没有必要支持古董级的版本，咱又不是Android）。因为iOS 3.2之前是不支持在Info.plist文件里面指定图标文件的，所以你得使用苹果指定的规范去命名图标文件。一个完整的列表差不多就是下面这个样子：
● Icon.png – 57×57 iPhone应用图标
● Icon@2x.png – 114×114 iPhone Retina显示屏应用图标
● Icon-72.png – 72×72 iPad应用图标
● Icon-72@2x.png - 144×144 iPad Retina显示屏应用图标
● Icon-Small.png – 29×29 iPhone 系统设置和搜索结果图标
● Icon-Small@2x.png – 58×58 iPhone Retina显示屏 系统设置和搜索结果图标
● Icon-Small-50.png – 50×50 iPad 系统设置和搜索结果图标
● Icon-Small-50@2x.png – 100×100 iPad Retina显示屏 系统设置和搜索结果图标
如果你的应用仅兼容iOS 3.2及之后的版本，那么你可以在Info.plist文件里面指定图标文件，你不用遵守上面的命名规范，当然你非要那么命名也没有问题（译者：为了便于和美工沟通和日后项目资源的管理，还是建议遵循这套规范）。在iOS 3.2中，苹果在Info.plist文件中引入了CFBundleIconFiles键，在此其中你可以直接指定应用图标的各种版本。如果你忽略了.png的后缀名，那么你也可以忽略高分版本图片的@2x部分，系统会自动匹配。
苹果在iOS 5.0中为了支持报刊杂志（Newsstand）功能，再次引入了一个新的键 CFBundleIcons，这让事情变得更加复杂起来（译者：再次叹气～）。这个键下含有子键CFBundlePrimaryIcon，里面的CFBundleIconFiles子键保存着在此之前保存在Info.plist根节点CFBundleIconFiles键里面的内容。如果你的应用仅支持iOS 5.0及之后版本，那么用一个 CFBundleIcons键就可以，否则的话你还需要同时保留CFBundleIconFiles键和相关内容。
（译者：这里原文讲述稍微有点偏差，未提到CFBundlePrimaryIcon，而且比较混乱，令人费解。其实在Xcode里面以默认方式打开Info.plist看到的会是Icon Files和Icon Files(iOS 5)两组键）
总之，为了做到向后兼容，这个环节会给开发者带来一点小混乱，相当容易犯错。所以，建议开发者针对不同的设备、屏幕组合多做测试。
三、应用商店截屏图片
苹果近期对应用提交做出了规则调整，如若是iPhone、iPod touch应用，必须提交Retina显示屏高分版本的应用屏幕截图。具体图片尺寸要求如下 (前面的尺寸是含系统状态栏情况下的截图):
- 横屏: 960×640 或 960×600
- 竖屏: 640×960 或 640×920
目前苹果尚未对iPad应用提交也做出类似要求，但是为了让你的应用截图在新iPad上看起来呼之欲出，现在是时候考虑使用高分版本截图了。对应的截图尺寸如下 (前面的尺寸是含有状态栏情况下的截图):
- 横屏: 2048×1536 或 2048×1496像素
- 竖屏: 1536×2048 或 1536×2008像素
译者注：原文评论中有人做了补充的，运行时的载入画面，针对新iPad屏幕也需要准备，文件命名和尺寸要求：
- 横屏: Default-Landscape@2x~ipad.png (2048×1496像素)
- 竖屏: Default-Portrait@2x~ipad.png (1536×2008像素)
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
ICON 设置 官网文档：http://developer.apple.com/library/ios/#qa/qa1686/_index.html
iPhone、iPad通用的设置
|
图片大小 (px) |
文件名 |
用途 |
重要程度 |
|
512x512 |
iTunesArtwork |
iTunes 商店中展示 在iTunes中获取iTunesArtwork图片 ①打开iTunes，点击左侧的iTunes Store，在选中的应用图标上右键 拷贝链接， 之后在浏览器中打开链接（这个链接是应用在AppStore上的介绍页面） 如：http://itunes.apple.com/cn/app/pocket-rpg/id411690524?mt=8 ②在显示的页面中，用浏览器上带的开发工具，定位到页面左上角的 175×175的应用ICON 如：http://a3.mzstatic.com/us/r1000/089/Purple/43/61/36/mzl.gvbidihl.175x175-75.jpg 之后将这个链接中的175x175改成512x512后，再打开就得到了对应的 iTunesArtwork图片了 http://a3.mzstatic.com/us/r1000/089/Purple/43/61/36/mzl.gvbidihl.512x512-75.jpg |
可以没有，推荐有 如果没有，在ituens中就不能显示图标，如图： 未知风格，是因为 Ad Hoc版本，就是测试版， 没有正式发布到App Store 上 |
|
57x57 |
Icon.png |
iPhone/iPod touch上的App Store以及Home界面 |
这个真得有 |
|
114x114 |
Icon@2x.png |
iPhone 4（高分辨率）Home 界面 [App Icons 设置中的Retina Display] |
可以没有，推荐有 |
|
72x72 |
Icon-72.png |
兼容iPad的Home界面 [App Icons 设置中的第一个图片] |
可以没有，推荐有 |
|
29x29 |
Icon-Small.png |
Spotlight搜索以及设置界面 |
可以没有，推荐有 |
|
50x50 |
Icon-Small-50.png |
兼容iPad的Spotlight搜索 |
如果有设置束，最好有 |
|
58x58 |
Icon-Small@2x.png |
iPhone 4（高分辨率）的Spotlight搜索和设置界面 |
如果有设置束，最好有 |
320x480 Default.png iPhone4 Launch Images
640*960 Default@2x.png iPhone4 Launch Images
640*1136 Default-568h@2x.png iPhone5
768x1024 Default-Portrait~ipad.png iPad Launch Images
1024x768 Default-Landscape~ipad.png iPad Launch Images
Default-Landscape~ipad.png专为iPad的应用程序
|
图片大小 (px) |
文件名 |
用途 |
重要程度 |
|
512x512 |
iTunesArtwork |
iTunes 商店中展示 |
可以没有，推荐有 |
|
72x72 |
Icon-72.png |
App Store以及iPad上的Home界面 |
这个真得有 |
|
29x29 |
Icon-Small.png |
iPad上的设置界面 |
如果有设置束，最好有 |
|
50x50 |
Icon-Small-50.png |
兼容iPad的Spotlight搜索 |
可以没有，推荐有 |
现在不提供iPhone4的必须图标Icon@2x.png，将通不过App Store的审核，所以，现在Icon@2x.png也是必须的了。
Standard display
30x30 .PNG, 24-bit with transparency (but use only 1 color). Worst case size ~350 bytes.标准的设置 tabicon.png
Retina display
60x60 .PNG, 24-bit with transparency (but use only 1 color). Worst case size ~2000 bytes. tabicon@2x.png
参考转自：http://shy818818.blog.163.com/blog/static/93398309201157104340600/
延长Default.png显示的时间
在delegate.m加入线程延迟
-(Bool)application:(UIApplication *)application didFinishLaunchingWithOptions: (NSDictionary *)launchOptions
{
[NSThread sleepForTimeInterval:10];
.............
}
应用的Default.png图片显示的时间 和 机器加载应用的速度成正比，加载越快，显示的时间越短，加载越慢，显示的时间越长，
感觉快的话，可以用上面方法延长它的显示时间
iOS设备现在有三种不同的分辨率：
iPhone 320x480,
iPhone 4 640x960,
iPad 768x1024。
以前程序的启动画面(图片)只要准备一个Default.png就可以了，但是现在变得复杂多了。
如果一个程序，既支持iPhone又支持iPad，那么它需要包含下面几个图片：
Default-Portrait.png iPad专用竖向启动画面 768x1024或者768x1004
Default-Landscape.png iPad专用横向启动画面 1024x768或者1024x748
Default-PortraitUpsideDown.png iPad专用竖向启动画面(Home按钮在屏幕上面)，可省略 768x1024或者768x1004
Default-LandscapeLeft.png iPad专用横向启动画面，可省略 1024x768或者1024x748
Default-LandscapeRight.png iPad专用横向启动画面，可省略 1024x768或者1024x748
Default.png iPhone默认启动图片，320x480或者320x460
Default@2x.png iPhone4启动图片640x960或者640x920
为了在iPad上使用上述的启动画面，你还需要在info.plist中加入
key: UISupportedInterfaceOrientations。
同时，加入值
UIInterfaceOrientationPortrait
UIInterfaceOrientationPortraitUpsideDown
UIInterfaceOrientationLandscapeLeft
UIInterfaceOrientationLandscapeRight。
iPhone上实现Default.png动画
原理：
添加一张和Default.png一样的图片，对这个图片进行动画，从而实现Default动画的渐变消失的效果。
操作：
在- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions中添加如下代码：
// Make this interesting.
UIImageView *splashView = [[UIImageView alloc] initWithFrame:CGRectMake(0,0, 320, 480)];
splashView.image = [UIImage imageNamed:@"Default.png"];
[self.window addSubview:splashView];
[self.window bringSubviewToFront:splashView];
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:2.0];
[UIView setAnimationTransition:UIViewAnimationTransitionNone forView: self.window cache:YES];
[UIView setAnimationDelegate:self];
[UIView setAnimationDidStopSelector:@selector(startupAnimationDone:finished:context:)];
splashView.alpha = 0.0;
splashView.frame = CGRectMake(-60, -85, 440, 635);
[UIView commitAnimations];
就ok了
Sizes of iPhone UI Elements
|
Element |
Size (in points) |
|
Window (including status bar) |
320 x 480 pts |
|
Status Bar |
20 pts |
|
View inside window (visible status bar) |
320 x 460 |
|
Navigation Bar |
44 pts |
|
Nav Bar Image / Toolbar Image |
up to 20 x 20 pts (transparent PNG) |
|
Tab Bar |
49 pts |
|
Tab Bar Icon |
up to 30 x 30 pts (transparent PNGs) |
|
Text Field |
31 pts |
|
Height of a view inside a navigation bar |
416 pts |
|
Height of a view inside a tab bar |
411 pts |
|
Height of a view inside a navbar and a tab bar |
367 pts |
|
Portrait Keyboard height |
216 pts |
|
Landscape Keyboard height |
140 pts |
Points vs. Pixels
The iPhone 4 introduced a high resolution display with twice the pixels of previous iPhones. However you don't have to modify your code to support high-res displays; the coordinate system goes by points rather than pixels, and the dimensions in points of the screen and all UI elements remain the same.
iOS 4 supports high resolution displays (like the iPhone 4 display) via the scale property on UIScreen, UIView, UIImage, and CALayer classes. If the object is displaying high-res content, its scale property is set to 2.0. Otherwise it defaults to 1.0.
All you need to do to support high-res displays is to provide @2x versions of the images in your project. See the checklist for updating to iOS4 or Apple documentation for Supporting High Resolution Screens for more info.
Adjusting Sizes
Click here to see how to adjust View Frames and Bounds.
Additional References
- Apple Documentation: Points vs. Pixels
- Apple Documentation: UIBarButtonItem Class Reference says "Typically, the size of a toolbar and navigation bar image is 20 x 20 points."
- Apple Documentation: UITabBarItem Class Reference says "The size of an tab bar image is typically 30 x 30 points."
// ----------------------------------------------------------------------------------------------------
圆角半径
iTunes Artwork icon ───────────────────────── 512px (90px)
App icon(iPhone4) ────────────────────────── 114px (20px)
App icon(iPad) ───────────────────────────── 72px (12px)
App icon(iPhone 3G/3GS) ───────────────────── 57px(10px)
Spotlight/Settings icon icon(iPhone4) ───────────── 58px (10px)
Spotlight/Settings icon icon(iPhone 3G/3GS/iPad) ──── 29px (9px)
=====================================================================
Designing an app for iPhone, iPad or iPhone4 Here's a couple of things to keep in mind:
iPhone & iPod Touch (1st, 2nd & 3rd Generation)
Portrait: 320 x 480 px, 320 x 480 point
Landscape: 480 x 320 px, 480 x 320 point
Status Bar: 20px, 20point
DPI: 163dpi
Color Mode: 8bit RGB
Color Temperature: Warm
Application icon: 57 x 57 px, 57 x 57 point
Appstore icon: 512 x 512 px, 512 x 512 point
Spotlight search icon: 29 x 29px, 29 x 29 point
Document icon: 22 x 29 px, 22 x 29 point
Webclip icon: 57 x 57 px, 57 x 57 point
Toolbar icon: 20 x 20 px, 20 x 20 point
Tab bar icon: 30 x 30 px, 30 x 30 point
Launch image: see above portrait/landscape
iPhone4
Portrait: 640 x 960 px, 320 x 480 point
Landscape: 960 x 640 px, 480 x 320 point
Status Bar: 40px, 20point
DPI: 326dpi
Color Mode: 8bit RGB
Color Temperature: Cool
Application icon: 114 x 114 px, 57 x 57 point
Appstore icon: 512 x 512 px, 512 x 512 point
Spotlight search icon: 58 x 58 px, 29 x 29 point
Document icon: 44 x 58 px, 22 x 29 point
Webclip icon: 114 x 114 px, 57 x 57 point
Toolbar icon: 40 x 40 px, 20 x 20 point
Tab bar icon: 60 x 60 px, 30 x 30 point
Launch image: see above portrait/landscape
Notes: effectively pixel-doubled previous generations, bare in mind the screen is the same size and concessions will have to be made e.g. keeping assets the same *physical size but doubling their effective resolution. see below.*
iPad
Portrait: 768 x 1024px, 768 x 1024point
Landscape: 1024 x 768px, 1024 x 768point
Status Bar: 20px, 20point
DPI: 132dpi
Color Mode: 8bit RGB
Color Temperature: Warm
Application icon: 72 x 72 px, 72 x 72 point
Appstore icon: 512 x 512 px, 512 x 512 point
Spotlight search icon (results): 50 x 50 px, 50 x 50 point
Spotlight search icon (settings): 29 x 29 px, 29 x 29 point
Document icon: 64 x 64 px, 64 x 64 point
Webclip icon: 72 x 72 px, 72 x 72 point
Toolbar icon: 20 x 20 px, 20 x 20 point
Tab bar icon: 30 x 30 px, 30 x 30 point
Launch image: see above portrait/landscape
Notes: many apps include a rounded mask at the corners of the screen/split view - its part of the default view of many apps by the OS. The radius of the rounded corner of these are 6px onto a black background and are optional.
Icon size radii (via Toxinide):
29x29px, border-radius: 5px
50x50px, border-radius: 9px
57x57px, border-radius: 10px
58x58px, border-radius: 10px
72x72px, border-radius: 12px
114x114px, border-radius: 20px
512x512px, border-radius: 90px
第三话:主要涉及常量命名、枚举命名、类及其方法命名，以及分类及其方法命名。
如果你找的是官网的编码规范，请移步: Coding Guidelines for Cocoa
- 常量命名
- 用枚举表示状态、选项、状态码
- 类及其方法命名
- 分类及其方法命名
常量命名
iOS 开发中，肯定避免不了要命名一些常量，那么，我们应该怎样来命名常量呢？
在讨论上述问题前，先来了解定义常量的两种方式。
第一种，使用 #define 预处理定义常量。例如：
#define ANIMATION_DURATION 0.3
定义一个 ANIMATION_DURATION 常量来表示 UI 动画的一个常量时间，这样，代码中所有使用 ANIMATION_DURATION 的地方都会被替换成 0.3，但是这样定义的常量无类型信息，且如果你在调试时想要查看 ANIMATION_DURATION 的值却无从下手，因为在预处理阶段ANIMATION_DURATION 就已经被替换了，不便于调试。因此，弃用这种方式定义常量。
第二种，使用类型常量。将上面的预处理定义常量修改成类型常量:
static const NSTimeInterval kAnimationDuration = 0.3;
这样就为常量带入了类型信息，那么定义类型常量又有什么规范呢？
- 对于局限于某编译单元(实现文件)的常量，通常以字符
k开头，例如上文中的kAnimationDuration，且需要以static const修饰，例如:
static const NSTimeInterval kAnimationDuration = 0.3;
- 对于定义于类头文件的常量，外部可见，则通常以定义该常量所在类的类名开头，例如
EOCViewClassAnimationDuration, 仿照苹果风格，在头文件中进行 extern 声明，在实现文件中定义其值:
EOCViewClass.h
extern const NSTimeInterval EOCViewClassAnimationDuration;
EOCViewClass.m
const NSTimeInterval EOCViewClassAnimationDuration = 0.3;对于字符串常量，则会像这样:
EOCViewClass.h
extern NSString *const EOCViewClassStringConstant;
EOCViewClass.m
NSString *const EOCViewClassStringConstant = @"EOCStringConstant";常量定义是从右往左解读，上面的示例中就是定义了一个常量指针，其指向一个 NSString 对象, 这样该常量就不会被随意修改。至于这种暴露出来的类常量最前面是否加上字母k, 可以根据自己习惯在团队中进行约定，因为从 iOS 的接口中我看到这两种情况都有, 如
NSString *const UIApplicationLaunchOptionsRemoteNotificationKey;
NSString *const UIApplicationLaunchOptionsLocalNotificationKey;还有:
NSString *const kCAAnimationCubic;
NSString *const kCAAnimationCubicPaced;用枚举表示状态、选项、状态码
项目中，可用枚举来表示一系列的状态、选项和状态码。例如 iOS SDK 中表示 UICollectionView 滑动方向的枚举定义如下:
typedef NS_ENUM(NSInteger, UICollectionViewScrollDirection) {
UICollectionViewScrollDirectionVertical,
UICollectionViewScrollDirectionHorizontal
};或者定义 UITableView Style 的枚举:
typedef NS_ENUM(NSInteger, UITableViewStyle) {
UITableViewStylePlain, // regular table view
UITableViewStyleGrouped // preferences style table view
};从这里可以看出，定义的枚举类型名称应以 2~3 个大写字母开头，而这通常与项目设置的类文件前缀相同，跟随其后的命名应采用驼峰命名法则，命名应准确表述枚举表示的意义，枚举中各个值都应以定义的枚举类型开头，其后跟随各个枚举值对应的状态、选项或者状态码。
对于需要以按位或操作来组合的枚举都应使用 NS_OPTIONS 宏来定义，例如 SDK 中:
typedef NS_OPTIONS(NSUInteger, UIViewAutoresizing) {
UIViewAutoresizingNone = 0,
UIViewAutoresizingFlexibleLeftMargin = 1 << 0,
UIViewAutoresizingFlexibleWidth = 1 << 1,
UIViewAutoresizingFlexibleRightMargin = 1 << 2,
UIViewAutoresizingFlexibleTopMargin = 1 << 3,
UIViewAutoresizingFlexibleHeight = 1 << 4,
UIViewAutoresizingFlexibleBottomMargin = 1 << 5
};这样定义的选项能够以 按位或操作符 来进行组合，枚举中每个值均可启用或者禁用某一选项，在使用时，可以使用 按位与操作符 来检测是否启用了某一选项，如下:
UIViewAutoresizing resizing = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
if (resizing & UIViewAutoresizingFlexibleWidth) {
// UIViewAutoresizingFlexibleWidth is set
}另外，我们可能使用 switch 语句时，会在最后加上 default 分支，但是若用枚举定义状态机，则最好不要使用 default 分支，因为如果稍后再加了一种状态，那么编译器就会发出警告，提示新加入的状态并未在 switch 分支中处理。假如写上了 default 分支，那么它就会处理这个新状态，从而导致编译器不发出警告，用 NS_ENUM 定义其他枚举类型时也要注意此问题。例如在定义代表 UI 元素样式的枚举时，通常要确保 switch 语句能正确处理所有样式。
总结一下:
- 应该用枚举来表示状态机的状态、传递给方法的选项以及状态码等值，给这些值起个易懂的名字。
- 如果把传递给某个方法的选项表示为枚举类型，而多个选项又可同时使用，那么就将各选项值定义为 2 的幂，以便通过按位或操作将其组合起来。
- 用 NS_ENUM 与 NS_OPTIONS 宏来定义枚举类型，并指明其底层数据类型。这样就可以确保枚举是用开发者所选的底层数据类型实现出来的，而不是采用编译器所选的类型。
- 在处理枚举类型的 switch 语句中不要实现 default 分支。这样加入新的枚举值之后，编译器就会发出警告提示，switch 还有未处理的枚举值。
类及其方法命名
Objective-C 没有其他语言那种内置的命名空间(namespace)机制。因此，我们在起名时要设法避免潜在的命名冲突，否则很容易就重名了。避免此问题的唯一方法就是变相实现命名空间: 为所有名称都加上适当前缀。所选前缀可以是与公司、应用程序或者二者皆有关联的名字。使用 Cocoa 和 Cocoa Touch 创建应用程序时一定要注意，Apple 宣传其保留使用所有"两个字母前缀"(tow-letter prefixed)的权利。所以你自己选用的前缀应该是三个字母的。你可以在苹果官网 Class Names Must Be Unique Across an Entire App 看到上述说明:
In order to keep class names unique, the convention is to use prefixes on all classes. You’ll have noticed that Cocoa and Cocoa Touch class names typically start either with NS or UI. Two-letter prefixes like these are reserved by Apple for use in framework classes.
Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app.
You should also name your classes using a noun that makes it clear what the class represents, like these examples from Cocoa and Cocoa Touch:
| NSWindow | CAAnimation | NSWindowController | NSManagedObjectContext
另外，在文档 Coding Guidelines for Cocoa 中提到:
Use prefixes when naming classes, protocols, functions, constants, and typedef structures. Do not use prefixes when naming methods; methods exist in a name space created by the class that defines them. Also, don’t use prefixes for naming the fields of a structure.
这里需要说明两点:
- 上述所说的
functions指的是纯 C 函数。对于纯 C 函数和全局变量，不论其处于头文件或者其实现文件中，在编译好的目标文件中，这些名称要算作"顶级符号"(top-level symbol)的。因此我们总应该为这种 C 函数的名字加上前缀。通常情况下，这类 C 函数我们可以以定义其类的名字作为前缀。这样，在调试时，若此符号出现在栈回溯信息中，则很容易就能判明问题源自哪块代码。例如:
ACLSoundPlayer.h
#import <Foundation/Foundation.h>
@interface ACLSoundPlayer : NSObject
@end
ACLSoundPlayer.m
#import "ACLSoundPlayer.h"
#import <AudioToolbox/AudioToolbox.h>
void ACLSoundPlayerCompletion(SystemSoundID ssID, void *clientData) {
}
@implementation ACLSoundPlayer
@end- 上述引用说到不应该为 Objective-C methods 添加前缀，我觉得应该添加一个例外，当我们定义分类中的方法时，则总应该为其添加前缀，这会在下一条详细说明。
最后一种情况，若为第三库编写自己的代码，并准备将其发布为程序库供他人开发应用程序所用时，你应该给你所用的那份第三方库代码都加上你自己的前缀。为便于说明，假如你要发布的程序库叫 EOCLibrary，你所使用的第三方库叫 XYZLibrary，则你应该把你使用的 XYZLibrary 中所有名字都冠以 EOC, 成为 EOCXYZLibrary, 原因如下:
- 你的程序所包含的那个第三方库也许还会为应用程序本身所引入。
- 你可能会想，让应用程序本身不要直接引入 XYZLibrary，改用 EOCLibrary 中使用的那个，但是，应用程序也许还会引入另一个名为 ABCLibrary 的第三方库，而该库中又包含了 XYZLibrary。此时，如果你和 ABCLibrary 的作者都不给各自所用的 XYZLibrary 加前缀，那么应用程序依然会出现重复符号错误。
- 你的库里所引用的第三方库是 X 版本的，而应用程序却需要引用第三库的 Y 版本的功能。
对于类中的方法命名，应遵循以下规则:
- 如果方法的返回值是新建的，那么方法名的首个词应是返回值的类型，例如:
+stringWithString:。除非前面还有修饰语，例如 localizedString。属性的存取方法不遵循这种命名方式。 - BOOL属性应加 is 前缀。如果某方法返回非属性的 Boolean 值，那么应该根据你功能，选用 has 或 is 当前缀。
分类及其方法命名
分类机制通常用于向无源码的既有类中新增功能。分类中的方法是直接加在类里面的，它们就好比这个类固有的方法，将分类方法加入类中这一操作是在运行期系统加载分类时完成的。运行期系统会把分类中所实现的每个方法都加入类的方法列表中。如果类中本来就有此方法，而分类中又实现了一次，那么分类中的方法会覆盖原来那一份实现代码。实际上可能会发生很多次覆盖，比如某个分类中的方法覆盖了"主实现"中的相关方法，而另外一个分类中的方法又覆盖了这个分类中的方法，多次覆盖的结果以最后一个分类为准。当有多份实现时，无法确定运行时使用的是那份实现。由这样引发的 bug 很难追查。
那么，如何来最大限度的避免这种覆盖呢?
在 iOS 开发中，没有命名空间的概念。通常，我们通过为项目中所有类命名加上特有的前缀来实现命名空间的功能，来避免可能发生的与使用第三方库中的方法命名相同。同样的，这里我们也是为分类，以及分类中的所有方法都加上特定前缀。这个前缀应该与应用程序库中其他地方所用的前缀相同，通常会使用公司名或应用程序名来做决定。例如来编写一个判断对象是否为空的分类方法:
NSObject+ACLNetworkingMethods.h
@interface NSObject (ACLNetworkingMethods)
- (BOOL)acl_isEmptyObject;
@end这里为分类名以及分类中的方法加上了 ACL 的前缀。注意在方法中，需前缀小写。
另外，使用分类时，不要刻意覆写分类中的方法，尤其是当你把代码发布为程序库供其他开发者使用时，因为你无法决定其他开发者需要的是方法哪份实现。
总结:
- 向第三方类中添加分类时，总应该给分类名称加上你专有的前缀，前缀须大写。
- 向第三方类中添加分类时，总应该给分类中的方法名加上你专有的前缀，前缀须小写，且以下划线连接前缀与方法名。