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

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

Objective-C七宗罪

一宗罪：.xib文件太大

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

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

二宗罪：無法使點(diǎn)語法保持一致

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

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

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

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

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

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

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

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

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

Objective-C這門語言以及其運(yùn)行時既是為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ǔ)類，而是一些嚴(yán)重混亂的C。

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

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

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

#p#

前10名編程語言走勢圖

20到50名語言排行

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