淺談Objective-C和Cocoa編程最佳實踐
淺談Objective-C和Cocoa編程最佳實踐是本文要介紹的內容，不多說，來看內容。在最新的3月TIOBE編程語言排行榜上，Objective-C份額仍在大幅增長，不斷向最主流語言行列接近。
在國外知名技術問答網站StackOverflow上，Objective-C標簽評分最高的問題是“What are best practices that you use when writing Objective-C and Cocoa?”盛大創新院高級研究員郝培強對其中有價值的回答進行了翻譯（翻譯原文），在得到譯者授權后，CSDN移動頻道轉載全文如下：
郝培強認為這些建議條目不是金科玉律，因為Objective-C和Cocoa的發展很快，希望每條都可以引起大家的思考，在自行驗證后再使用到自己的項目里面去。
有些初學時的做法，現在我認為是不標準的。
（1）有了property，在“私有”的成員變量前面不再使用"_"前綴。如果一個成員變量可以被其他的類訪問，那就應該用property。我不喜歡“_”前綴，它會把代碼弄得非常丑陋，現在終于可以不用它了。
（2）說起來私有，我傾向于把似有方法定義在.m文件里，放在一個私有的category內，如下：
- #import "MyClass.h"
- @interface MyClass ()
- - (void) someMethod
- - (void) someOtherMethod
- @end
- @implementation MyClass
Why clutter up the .h file with things outsiders should not care about（這句怎么翻譯說不準）？.m文件里的空括號的作用是私有category，如果你不實現里面聲明的方法，會引發編譯警告。
（3）我把dealloc方法放在.m文件的頂部，緊挨著@synthesize語句。需要dealloc哪些東西，難道不應該是你考慮一個類的時候的首要問題么？尤其是在iPhone這種環境下。（譯注：我也是這么做的，dealloc和init之類的放在一起，可以對照。默認的模版把dealloc放在最后面，不利于對照，也容易讓人忽視dealloc）
在table cell里，為了性能令所有的元素不透明（包括cell本身）。也就是說，每個東西都設置恰當的背景色。
使用NSURLConnection時，你應該實現下面的delegate方法
- - (NSCachedURLResponse *)
- connection:(NSURLConnection *)
- connection willCacheResponse:(NSCachedURLResponse *)
- cachedResponse {
- return nil;
- }
除非你希望緩存response，否則你大多數時候會覺得web調用都是反常的，尤其是web service調用。如上實現這個方法可以避免緩存任何的response。
（4）避免double。iPhone原生不支持任何的double精度運算。它們是使用庫來模擬的。僅在你必須使用的時候使用double精度，例如CoreLocation。在數字常數后面使用f后綴，令編譯器把它們當作float處理。
- float val = someFloat * 2.2f;
更重要的是當someFloat是double的時候，你不需要混合精度計算，因為val已經把精度損失掉了。更新：在3GS上發生了些變化，更應該用float了：
即使在某些手機上看起來計算不同精度速度一樣，但是float可以放更多數據在寄存器里，所以還是會快很多。(譯注：程序不是計算為主的，就不必那么在乎了。)
（5）把property設置為nonatomic。atomic是默認值，是同步的，會自動加入同步代碼避免在多線程時發生問題。但是99%的情況下，你的property不會在多線程環境下訪問，用nonatomic可以避免代碼臃腫提高效率。（譯注：也就是說如果要在多線程環境下訪問property，切記用atomic，或者自行加鎖）
（6）SQLite保存大數據集非常非常快。例如地圖程序應該把圖塊緩存在SQLite里。最昂貴的部分是硬盤I/O。要避免在大塊之間產生大量的小的寫入，就需要用BEGIN; 和COMMIT;。我們使用2秒鐘的計時器去重置每次新的提交。一旦計時器國企，就發送COMMIT;，這樣所有些操作就寫到一個大塊里面了。SQLLite把事務數據保存在磁盤上，使用Begin/End包裝可以避免產生大量的事務文件，把所有的事務寫到一個文件里。
當SQLite在主線程的時候會阻塞你的界面。如果你執行非常長的查詢，一個好辦法是把你的查詢保存成靜態對象，然后在另一個線程查詢。把所有會修改數據庫的查詢用@synchronize() {}塊包起來。
短查詢就放在主線程，簡單方便。（譯注：我在多線程里面使用SQLite的方法更簡單，用sqlite3_open_v2打開數據庫，flag用SQLITE_OPEN_FULLMUTEX，這樣SQLite的所有函數就是線程安全的了，不需要synchronize了，不過哪個效率更高，我不知道。）
更多SQLite優化技巧在此，雖然文章很老，但是觀點貌似都還對：
http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html
以前outlet的內存管理沒什么好辦法。現在的最佳實踐是把outlet聲明為property：
@interface MyClass :NSObject { NSTextField *textField; } @property (nonatomic, retain) IBOutlet NSTextField *textField; @end
使用property，內存管理語義更清晰；同時給其他的實例變量組織提供了一個統一的模式。
譯注：這條值得商榷，一般來說不需要跨類存取的變量，是否是IBOutlet，我都認為盡量不要聲明為property。這篇問答比較早，有很多信息也許不夠新了。翻出來主要是給大家參考的。
使用LLVM/Clang靜態分析器：
原文我不翻譯了，最近的Xcode版本都已經內置包含了LLVM/Clang靜態分析器，使用方法很簡單：
Xcode3系列使用熱鍵Shift+Command+A
Xcode4系列使用熱鍵Shift+Command+B
為了保證效果，使用靜態分析器前，最好Shift+Command+K清除一下Build。
靜態分析器可以分析出很多濫用，不和規范的用法，特別是能夠幫你找到潛在的內存泄漏。但是它不是萬能的，如果你的代碼邏輯很亂，尤其是內存管理大量都不符合規范，那么它也可能給出錯誤的建議。它的建議起作用的前提是，你大量的代碼都符合Objective-C和Cocoa的規范，有少部分代碼忘記了release之類的，那么它會給你很好的建議。
所以，永遠都沒有神仙皇帝，好好寫代碼是基礎。
使用標準的Cocoa命名和格式規范以及術語。規范的好處是和別的Cocoa開發者合作的時候，更方便。
例如，應該做和不應該做的：
* 在對象的interface里不要聲明id m_something，不要把它叫做成員變量或者字段；使用something或者_something(這個現在也不建議了)作為它的名字，叫它實例變量。
* getter不要叫-getSomething；應該為-something;。
* setter不要叫做-something；應該叫-setSomething:。
* 方法名由參數和冒號組成；形如-[NSObject performSelector:withObject:]而不是NSObject::performSelector。
* 方法名，參數，變量，類名使用駝峰式命名（由多個單詞組成一個名稱時，單詞首字母大寫，單詞間無空格，無下劃線）。
* 類名首字母大寫，變量，方法名首字母小寫。
不管怎么做，絕對不要用Win16/Win32風格的匈牙利命名法。即使微軟在轉向.NET平臺時，也都拋棄了它。
小結：淺談Objective-C和Cocoa編程最佳實踐的內容介紹完了，希望本文對你有所幫助！
