IOS 命名規範
第一話:項目名稱命名規則
小駝峯命名法(CamelCase)：第一個單詞小寫字母開頭，其餘單詞首字母大寫；
大駝峯命名法(PascalCase): 全部首字母大寫。
命名規範：
一、類名、協議名：遵循大駝峯命名法；
二、常量：這裏的常量指的是宏(#define)、枚舉(enum)、常量(const)等，使用小寫」k「做爲前綴，名稱遵循大駝峯命名法。
三、方法
* 方法名和方法參數遵循相同的規則，使用小寫開頭的小駝峯法；
* 方法名和參數儘可能讀起來像是一句話；
* 方法名不容許使用「get「前綴；
* -或+與返回類型間留一個空格，但參數列表之間不要留間隔；
* 若是參數過多，推薦每一個參數各佔一行；
四、變量：
類成員變量，屬性，局部變量，使用小寫開頭的小駝峯法，其中類成員變量在名稱最後加一個下劃線，html
好比:myLovalVariable, myInstanceVariable_ ；變量名的名稱儘可能能夠推測其用途，具備描述性。
書寫規範：
1. 在m文件中對當前類屬性進行引用的時候，使用self.property的方式，用以區分局部變量；對屬性進行賦值的時候使用「點」賦值，即A.property = value;
2. 使用import引用頭文件的工做所有放到 .h 文件中進行，m文件只保持對當前類頭文件的引用；
3. 若是m文件中有較多的method，使用 #pragma mark 標記對方法進行分組，便於查看ios
第二話:ios項目icon和default圖片命名規則
1、應用圖片瀏覽器
標準iOS控件裏的圖片資源，蘋果已經作了相應的升級，咱們須要操心的是應用本身的圖片資源。就像當初爲了支持iPhone 4而製做的@2x高分辨率版本（譯者：如下簡稱高分）圖片同樣，咱們要爲iPad應用中的圖片製做對應的高分版本。我知道很多開發者頗有預見性的早在iOS 5.0 SDK上就完成了這一步升級。但是我仍是要強調一點，那就是以前 Michael Jurewitz (@Jury)在推上提到過的：app
— 若是想讓你的高分圖片顯示在新iPad上，你必須用Xcode 4.3.1 連同iOS 5.1 SDK編譯！iphone
2、應用圖標
接下來確定就是爲應用主圖標製做高分版本了，由於低分版的圖標在新iPad桌面上看起來會慘不忍睹。爲了支持更多的iOS設備、更高分辨率的屏幕，iOS開發者須要爲本身的應用準備各類尺寸的主程序圖標文件，並且這個文件列表貌似會愈來愈長愈來愈長……（譯者：嘆氣～）。詳情請參考最新的蘋果開發者文檔 iOS App Programming Guide 和 iOS Human Interface Guidelines 。從官方文檔中，我找出來針對新iPad的Retina顯示屏咱們須要準備的東西：
iPad主應用圖標 (144×144像素)：以前用在iPad 一、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)兩組鍵）
總之，爲了作到向後兼容，這個環節會給開發者帶來一點小混亂，至關容易犯錯。因此，建議開發者針對不一樣的設備、屏幕組合多作測試。
3、應用商店截屏圖片
蘋果近期對應用提交作出了規則調整，如如果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像素)ide
-----------------------------------------------------------------------------------------------------------------------------函數
-----------------------------------------------------------------------------------------------------------------------------工具
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 的前綴。注意在方法中，需前綴小寫。
另外，使用分類時，不要刻意覆寫分類中的方法，尤爲是當你把代碼發佈爲程序庫供其餘開發者使用時，由於你沒法決定其餘開發者須要的是方法哪份實現。
總結:
- 向第三方類中添加分類時，總應該給分類名稱加上你專有的前綴，前綴須大寫。
- 向第三方類中添加分類時，總應該給分類中的方法名加上你專有的前綴，前綴須小寫，且如下劃線鏈接前綴與方法名。
- 1. iOS－OC命名規範
- 2. 命名規範
- 3. Java命名規範
- 4. iOS開發規範-素材命名
- 5. iOS開發（OC）中的命名規範
- 6. CSS命名規範
- 7. Android 命名規範
- 8. winform命名規範
- 9. mysql命名規範
- 10. c++命名規範
- 更多相關文章...
- • XML 命名空間 - XML 教程
- • C# 命名空間（Namespace） - C#教程
- • Docker 清理命令
- • 三篇文章瞭解 TiDB 技術內幕 —— 說計算
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. CVPR 2020 論文大盤點-光流篇
- 2. Photoshop教程_ps中怎麼載入圖案？PS圖案如何導入？
- 3. org.pentaho.di.core.exception.KettleDatabaseException:Error occurred while trying to connect to the
- 4. SonarQube Scanner execution execution Error --- Failed to upload report - 500: An error has occurred
- 5. idea 導入源碼包
- 6. python學習 day2——基礎學習
- 7. 3D將是頁遊市場新賽道？
- 8. osg--交互
- 9. OSG-交互
- 10. Idea、spring boot 圖片(pgn顯示、jpg不顯示)解決方案
- 1. iOS－OC命名規範
- 2. 命名規範
- 3. Java命名規範
- 4. iOS開發規範-素材命名
- 5. iOS開發（OC）中的命名規範
- 6. CSS命名規範
- 7. Android 命名規範
- 8. winform命名規範
- 9. mysql命名規範
- 10. c++命名規範