變量的駝峰命名法的特例處理

使用駝峰命名法(Camel Casting)的時(shí)候總是會(huì)為縮寫,常用語該怎么表示產(chǎn)生困惑,網(wǎng)上搜索了一下,發(fā)現(xiàn)一篇文章。由于文章是需要medium 訂閱的,因此我連翻譯帶補(bǔ)充了一下。

每種語言都有自己的命名習(xí)慣,尤其在遇到縮寫的情況,例如: JSON orJson, URL or Url, HTTP or Http。在使用 Camel Casting 的時(shí)候怎么命名一直沒有一致的標(biāo)準(zhǔn)。

一種“簡(jiǎn)單”的回答是: 遵循你所使用的語言的規(guī)范或框架的規(guī)范。這種回答其實(shí)還是沒有標(biāo)準(zhǔn)。而上述情況是如此常見,因此無論如何我們總需要把“共識(shí)”再推進(jìn)一步。

問題來源于縮寫 (ID -> Identifier)和簡(jiǎn)寫 (HTTP -> HyperText Transfer Protocol), 甚至一些特殊的形式進(jìn)行約定,例如 IPv6, IoT iOS 等。

下面列出了一個(gè)將英語短語轉(zhuǎn)變?yōu)?camelCase 的思路。

從英語短語到 camelCase 的轉(zhuǎn)換算法

  • 首先: 轉(zhuǎn)換英文短語到 ASCII,移除全部撇號(hào),省略號(hào)等,例如:
    • “Müller’s algorithm” 轉(zhuǎn)換為 “Muellers algorithm”
  • 將上面的成果以單詞邊界進(jìn)行分隔 (以空格、連字符、下劃線來分隔)

有些英語短語已經(jīng)有 Camel Case 了,例如: AdWords 是 “ad words” 轉(zhuǎn)化后的結(jié)果,那么你需要把它們先反向解析為 “ad words”。注意 IoT、iOS 不應(yīng)該出現(xiàn)在這種詞匯表里,因?yàn)樗鼈兪强s寫,不是完整的單詞組成的短語。

  • 然后,將全部字母轉(zhuǎn)小寫,包括縮寫和簡(jiǎn)寫,但是對(duì)于以下單詞進(jìn)行首字母大寫:
    • 如果僅有一個(gè)單詞,則不進(jìn)行任何首字母大寫的轉(zhuǎn)換
    • 如果有多個(gè)單詞,對(duì)第一個(gè)單詞之外的其他單詞進(jìn)行首字母大寫轉(zhuǎn)換
  • 最終,將所有轉(zhuǎn)換后的單詞連接起來,但是:
    * 如果某個(gè)單詞只有一個(gè)字母,且不是短語中的最后一個(gè)單詞,那么這個(gè)單字母單詞必須和下一個(gè)單詞連接在一起,例如:
    * btreeMap (??), bMapTree (??), threeM (??)
短語 正確 錯(cuò)誤
"XML Http Request" xmlHttpRequest XMLHTTPRequest
"new customer ID" newCustomerId newCustomerID
"inner stopwatch" innerStopwatch innerStopWatch
"supports IPv6 on iOS" supportsIpv6OnIos supportsIPv6OnIOS

其中有個(gè)特例,iOS 還是 IOS?考慮到已經(jīng)有了一些常用的用法,例如在 ReactNative 中的 ActionSheetIOS 或者 LinkingIOS之類,所以建議用 IOS 而不是 iOS,因此,supportsIpv6OnIos -> supportsIpv6OnIOS。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容