現有命名方法彙整及比較

命名規則是為了增加識別和可讀性,沒有強制的規定,但一旦選擇其中一種,會建議編寫時統一格式;而化學、天文、生物也有其慣用的命名方法;大部分的程式語言也有對此進行建議,以統一風格。

在程式設計的命名上,當變數、函式及類別等名稱由兩個以上的單字組合,就可以使用現有的命名方法,增加識別和可讀性。目前已經出現的命名方法,可以分為Underscore(底線式)、Camel-case(駝峰式)及Hungarian notation(匈牙利命名法)三大類。此文進行彙整,並以個人經驗,探討其優缺點。


一、Underscore(底線式):

單字之間使用底線分隔,GNU/Linux環境中最常見,例如:string_name。

優點:

使用底線取代空格,閱讀上比較直覺易懂。

缺點:

比起Camel-case使用字首大寫取代空格,底線比較少在日常輸入,因此需要適應。


二、Camel-case(駝峰式):

單字之間使用大寫分隔,又可以分為Lower Camel-case(小駝峰式),或Upper
Camel-case(大駝峰式),而後者又稱為Pascal-case(帕斯卡式)。

Lower Camel-case(小駝峰式):
第一個字母用小寫,此變化常用在變數名稱上,例如stringName。

Upper Camel-case(大駝峰式):
第一個字母用大寫,此變化常用在函數、類別、屬性及命名空間上,例如StringName。

優點:

  • 可以利用名稱前綴的大小寫,區分變數,以及函數、類別等其他型別。
  • 單字之間使用大寫取代底線,能夠減少名稱的長度,減少程式碼超出視窗被遮擋的情況。

缺點:

  • 比起Underscore使用底線取代空格,閱讀上較不直覺易懂。

三、Hungarian notation(匈牙利命名法)

在Camel-case(駝峰式)的基礎上,在名稱前綴添加預先約定好的縮寫,例如約定如下:

b       boolean
c       character
str     C++ String
si      short integer
i       integer
li      long integer
f       floating point
d       double-precision floating point
ld      long double-precision floating point
sz      Old-Style Null Terminated String
if      Input File Stream
is      Input Stream
of      Output File Stream
os      Output Stream
S       declaring a struct
C       declaring a class

Source: http://web.mst.edu/~cpp/common/hungarian.html

根據縮寫用途的不同,又可分為Systems Hungarian,以及Apps Hungarian。

Systems Hungarian
名稱前前綴代表的是實際的資料型別,例如:strName。

Apps Hungarian
名稱前綴代表的是目的或其他提示,例如:usName,其中us代表unsafe,為了避免Code injection或XSS,之後必須進行過濾處理。

優點:

  • 不需要IDE支援,就能夠從名稱能看出型別。
  • 制定好的編碼規則,能夠在搜尋時更加統一易找。
  • 制定好的編碼規則,能夠在命名及輸入上更快。

缺點:

  • 需要另外學習編碼規則。
  • 現代IDE已經可以輕易的區分型別,在資料型別上,此方法稍嫌多餘。
  • 變數型別修改時,名稱也必須修正維護。
  • 採用縮寫來命名,對新手較不友善,例如szName,不如stringZeroName。
  • 也更容易造成歧義,例如szName,更容易被誤讀成其他意思,也難以透過猜測關鍵字搜尋。

主流通訊協定介紹(RPC、SOAP、REST)

Remote Procedure Call (RPC)

起源於1976年,允許Client遠端呼叫Server的子程式,然後將執行結果返回給Client;當時的傳輸資料常使用二進制格式,為了統一資料傳輸格式,隨後出現了XML-RPC, XML作為資料交換語言的RPC機制。

Simple Object Access Protocol (SOAP)

起源於1998年,由於RPC經常被Firewall及Proxy Server阻擋,為解決兼容及安全性問題,採用HTTP(起源於1989)是更好的方法,SOAP還提供了一套標準方法讓程式間可以互相通信。可以簡單把SOAP當作RPC+XML+HTTP(POST only)+有狀態的通信方法。

Representational State Transfer (REST/RESTful)

起源於2000年,由於SOAP過於複雜且依賴狀態,REST提倡使用標準的HTTP中的四種動作GET、PUT、POST及DELETE,以及Uniform Resource Identifier (URI)來指定資源,降低開發的複雜性。可以簡單把REST當作PRC+XML+HTTP(GET,PUT,POST,DELETE)+URI+無狀態的通信方法。

發展趨勢

REST風格相比XML-RPC及SOAP更加簡潔易用,而JSON資料交換語言相較XML更加輕量,目前大多數的Web Service都採用REST+JSON作為傳輸方法。

CI/CD筆記

流程

  • 持續整合(Continuous Integration)
    • Code Repository
    • Version Control
    • Build
    • Integration
  • 持續交付(Continuous Delivery)
    • Release
    • Delivery
  • 持續佈署(Continuous Deployment)
    • Production

評比指標

  • 佈署頻率(Deployment Frequency)
  • 變更前置時間(Change Lead Time)
  • 服務恢復時間(MTTR)
  • 變更失敗比率(Change Fail Rate)

常用工具

  • CI / CD
    • Jenkins
    • Gitlab CI
    • Travis CI
    • Circle CI
    • Drone
  • Version control
    • Bitbucket
    • GitHub
  • POM
    • Maven
  • Code Quality and Security
    • SonarQube
  • Unit Test
    • TestNG
  • Test Automation
    • Selenium
    • Appium

軟體設計模式筆記

  • 裝飾者模式:包裝一個物件,以提供新的行為。
  • 適配器模式:封裝物件,並提供不同的介面。
  • 模板方法模式:由子類決定如何實現一個演算法中的步驟。
  • 工廠方法模式:由子類決定要創建哪個類別的實體。
  • 單件模式:確保有且只有一個物件被創造。
  • 策略模式:封裝可以互換的行為,並使用委託來決定要使用哪一個。
  • 組合模式:客戶用一致的方式處理物件集合和類別物件。
  • 狀態模式:封裝了基於狀態的行為,並使用委託在行為之間切換。
  • 疊代器模式:在物件的集合之中游走,而不是暴露集合的實現。
  • 外觀模式:簡化一群類的介面。
  • 裝飾者模式:包裝一個物件,以提供新的行為。
  • 抽象工廠方法:允許客戶創建物件的家族,而無需指定他們的具體類。
  • 觀察者模式:讓物件能夠在狀態改變時被通知。
  • 代理模式:包裝物件,以控制該物件的訪問。
  • 命令模式:封裝請求成為物件。