【51CTO專稿】在2009年夏之前， Objective-C做為一種編程語言幾乎沒人認識和使用。直到iPhone和iPad的成功，Objective-C就開始以令人難以置信的速度往頂部攀升。這就導(dǎo)致了在2011-2012連續(xù)2年獲得了TIOBE年度獎項，不過在最近一段時間，預(yù)計Objective-C不會再繼續(xù)上升。很多人會認為Objective-C上升變得緩慢或下降的主要原因是iPhone5的銷售量不佳，界面的審美疲勞，3.15的一些問題導(dǎo)致?；蛘哂忠驗橛肙bjective-C語言開發(fā)確實不是太理想，導(dǎo)致一些個人開發(fā)者對其放棄?？傊?，Objective-C目前確實遇到了瓶頸。

不過C和Java確實沒什么好說的現(xiàn)在，兩兄弟現(xiàn)在打的不分上下，很難分個高低。關(guān)于詳細的排名請看下圖：

Objective-C七宗罪

一宗罪：.xib文件太大

我之所以說Objective-C不好，有幾個原因，最大的問題是當(dāng)系統(tǒng)加載系統(tǒng).xib時，需要加載整個.xib；并且在啟動應(yīng)用程序或者用戶交互響應(yīng)環(huán)節(jié)時占據(jù)大量時間，這一點很讓人頭疼。

第二個問題是，無法重復(fù)使用視圖（或者與它相關(guān)聯(lián)的代碼），你總不會希望一直重復(fù)粘貼與復(fù)制吧。

二宗罪：無法使點語法保持一致

談及Objective-C的語法，很多開發(fā)者第一感覺就變成望而卻步了。

許多開發(fā)者總認為使用點語法編寫是主觀現(xiàn)象，也許他們的想法是正確的。但是我個人認為點語法是一個較為現(xiàn)代化的方式來訪問屬性，這不屬于客觀現(xiàn)象。相反，如果你選擇使用點語法，并且一直堅持這么做。那么，建議你要么全部使用，要么干脆不要，記住，千萬不要混合及匹配使用 。

三宗罪：.m Files中的類繁多

在一個相同的文件里會出現(xiàn)很多類，這是一個很主觀的現(xiàn)象，因為這往往會利用一個有用的方式來定義，就如同小包裝模型類或者值轉(zhuǎn)換。

如果外部文件需要使用你的新類，把它放在自己的文件夾中即可。如果你#import一個視圖控制器僅僅是為了在.m file里面得到一個輔助類，那么要把重構(gòu)擺在首位。

四宗罪：無法進行編譯器優(yōu)化測試

當(dāng)你開發(fā)時通常會使用Xcode默認選項——關(guān)閉優(yōu)化，但最終發(fā)布前肯定還是會開啟它的，這時經(jīng)常會出嚴重的問題。

你無需調(diào)優(yōu)編譯器來做完整的回歸測試，只需一個簡單的smoke測試就足夠了。如果你有beta測試人員，那么可以進行設(shè)置，重要的是某人在測試之外能夠生成二進制文件以確保用戶能夠被控制。

五宗罪：體系結(jié)構(gòu)的基本類型

Objective-C這門語言以及其運行時既是為iOS，也是為OS X而開發(fā)的。但iOS 32位而OS X是64位的。當(dāng)你使用Objective-C定義原始值的時，使用int將會出現(xiàn)丟失；如同為OS X編譯時出現(xiàn)的那些半位，使用long int又顯得太蠢了。

六宗罪：不必要的-C APIs

什么是Keychain API？新的OS X APIs需要使用Sandboxing，但需要使用C嗎？這里我討論的不是核心基礎(chǔ)類，而是一些嚴重混亂的C。

C語言比Objective-C快不了多少。如果你想做任何實時系統(tǒng)方面或者處理音頻或視頻，可選擇使用C。在大多數(shù)情況下Objective-C是不錯的選擇。

七宗罪：無法使用自動化測試

你是否使用Objective-C進行單元測試？也許你不曾使用過。那么你曾給UI進行自動化驗證測試嗎？答案也是NO。那你曾設(shè)置過任何持續(xù)集成嗎？

#p#

前10名編程語言走勢圖

20到50名語言排行

下面是第50到100的編程語言排名