不需聲明,甚至匿名方式原地定義。編碼量少。 這一條在 C++ 中尤其明顯,以綁定一個回調(diào)為例,需要聲明,定義,調(diào)用綁定,三處代碼。雖然 C++11 中支持 lambda 表達式,對于回調(diào)的寫法有很大改進。但是其他地方依然蛋疼。
弱類型語言,一般情況下,不需關(guān)心實際類型。Debug 時除外。
在使用 C++ 這種強類型語言的開發(fā)中,尤其是寫功能代碼時,類型檢查遠不如想象中那么有用,很多時候反而是問題根源,編譯不通過時,很大一部分時間是在對變量類型,由此還衍生出一些特殊技術(shù)手段,比如適配器模式等等。
使用 JS 這種弱類型語言,只要接口名稱能對上,那么在對象的函數(shù)被調(diào)用時就認為是正確的。簡單說,只要長得像某一類型就行了,不需要必須是某一類型。
C++11 中 auto 關(guān)鍵字也可以提升編碼速度(和 JS 的 var 很類似,可以隨時無腦輸出),不過看了一下引擎附帶的幾個例子代碼,好像有濫用 auto 的趨勢。
腳本語言動態(tài)擴展能力強,可以不必構(gòu)造很多臨時類型和消息類型。 比如,在大型游戲中,全局使用消息機制時,C++ 可能用結(jié)構(gòu)體,自定義類,或者我們以前直接丟J SON 對象過去。在 JS 里面就很簡單了,直接扔 JSON 對象吧。 在運行時可以動態(tài)給一個對象添加函數(shù)和屬性,而不需要重新構(gòu)造新類和初始化。JSON 源自 JS,JSON 是天然的消息對象,非常合適。當然 JSON 有自身的缺點,訪問父節(jié)點和兄弟節(jié)點不太方便。并且 JSON 的結(jié)構(gòu)和二維表沒法完全兼容,這是一直讓策劃和工具程序員頭痛的一個問題。
語法靈活,可以支持各種編碼方式。隨機應(yīng)變。
業(yè)界普遍認為面向?qū)ο笤趫D像編程是最好的。但對于事件處理邏輯處理AI處理來說,面向?qū)ο髣t是羅嗦的要死。比如,我實在對觀察者模式提不起興趣,Qt 中的信號槽機制優(yōu)雅的多。又比如我曾經(jīng)做了一個 A* 算法代碼,想改成好用的面向?qū)ο蠓绞?,發(fā)現(xiàn)很痛苦。
JS 很靈活,適合什么樣的編碼方式,就用什么樣的方式。
在語言級別天生集成了兩種最有用的數(shù)據(jù)結(jié)構(gòu),向量和映射表。 記得在 KJava 時代,MIDP 的里面只有很少的數(shù)據(jù)結(jié)構(gòu),里面就有向量和哈西表。這兩種是最為常用的。JS 在語言層面提供了支持,編碼極其方便。
太靈活,更容易出爛代碼。
調(diào)試問題與 IDE 問題。
目前在 cocos2d-x 領(lǐng)域,還缺乏好用的支持 JS 的 IDE ?,F(xiàn)在目前暫時還是用 cocos2d-html5 版本做調(diào)試(兩者的接口已經(jīng)高度一致化),未來會有基于 c++ 的 IDE 做的 JS 調(diào)試插件(比如在 Eclipse 上面的)。
善變的 this
this 關(guān)鍵字絕對是 JS 里面的變形金剛。根據(jù)不同的上下文,經(jīng)常會變成其他東西。
這個經(jīng)常會和回調(diào)函數(shù)問題糾纏不清,如果再加上閉包,三合一,夠你喝一壺的。
閉包
閉包很強大,無限制傳參,抓取快照。
但是閉包本身的問題也不小,首先是閱讀和理解上的困難,面向?qū)ο蟮某绦騿T一上來很難理解這東西,從他們的角度看閉包的代碼也很丑。
還有就是效率問題,同事測了一下 SpiderMonkey 中的閉包在生成大對象時效率不太高。
目前在 cocos2d-x 前端開發(fā)中,為了防止出現(xiàn)問題,對于缺乏經(jīng)驗的程序員,盡量不要使用閉包代碼。
我個人在回合制戰(zhàn)報,生成動畫里是用了一些閉包的,不過那是一次性代碼。
變量生命周期不明確
變量生命周期問題,因為不需要聲明,很多時候也沒有特別明顯的初始化,并不能通過閱讀代碼明確知道,一個變量的生存周期,這是所有腳本語言和 GC 語言的特性,有些時候?qū)φ{(diào)試會形成麻煩。
從靜態(tài)語言過度到動態(tài)腳本語言,一般程序員會疑惑在幾個地方,this,閉包,原型繼承,以及如何靈活地使用腳本語言的動態(tài)性進行編碼,我觀察了一下,很多人寫 JS 像靜態(tài)語言,還是 c++ 風格或者 Java 風格。