如果你是一個寫程式的老手,你可能用過很多種有著不同基礎哲學的程式語言;你用過Perl嗎?它的概念跟Algol有很大的不同;直譯的Basic語言是如此容易,讓很多人能進入這個領域,而Visual Basic則是一頭完全不同的「怪獸」。

我的第一種語言(在母語英語之後)是Fortran,我用過不少它的分支語言以及編譯器。組合語言(Assembly)…嗯,就是組合語言,不是有太多人能說出個所以然;C語言基本上是組合語言,在生產力方面有大幅改善。

C++語言在我看來充滿了相當的複雜度以及黑暗之處,聰明的人最好不要踩到。還有Java語言是一種有趣的物件導向(OO)方法,但其垃圾回收(garbage collection)機制以及缺乏指標(pointer)等特性,使該語言不適合大多數的嵌入式開發。

C語言多年來在這個產業界是流行語言,調查資料顯示(如下圖),該語言在嵌入式領域的市佔率最高,而且其地位數年來屹立不搖,許多新一代的語言如Python都仍遠遠落後,C將會在很長一段時間繼續是主力語言。

20160418 FixingC NT03P2 各種程式語言的使用情況統計

但C語言已經很「老」了,也受到那樣的長壽影響;該語言隱藏了遲鈍點,批評者指出,C語言開發者似乎厭惡打字;那大多數來自不良習慣,像是使用非常短的變數名稱(variable names)。任何一種語言都會被濫用,但對比典型的C程式,例如Ada程式碼,有人確實會疑惑為何我們看起來如此簡潔,該語言本身就很簡潔。

假設你可以用魔法改變C語言的某一個方面,你會改變哪裡、為什麼?我會想要擺脫花括號(即{},又稱波型括弧);我們都曾經歷來自深度套疊的程式碼段落之錯誤以及編譯器抱怨(compiler complaints),我們會搞混需要多少結束括號以及它們該被放置在哪裡。

我比較喜歡需要匹配開始與結束段落,以終結聲明(end statement)來指示哪個段落已經結束;例如:

20160418 FixingC NT03P1

這需要打更多字,但任何一個軟體開發者如果打字不夠快就是入錯行了;其好處是更容易了解段落在哪裡開始與結束。當然,謹慎地縮排也能告訴我們相同的事情,但今日有太多程式碼被這麼多人修改過,原始工程師精心地縮排通常變成無可救藥的錯位。可能很難知道哪一個括號是結束哪一個段落,被誤放的括號可能會讓編譯器發瘋。

而深度套疊控制架構當然也可能導致大量連續的「end if」聲明,這可能會是例外而不是規則;並沒有「銀彈」可以拯救我們,但小小的改變,像是利用開始/結束聲明而非括弧,有可能帶來非常大的幫助。

我通常會在註解的地方針對哪個括弧是結束哪個段落做記號,但如果程式語言能像我說的,編譯器能指出遺失以及被混淆的「end」聲明豈不是更好?其他有的語言指令就包含標籤的結束聲明並因而獲益,Ada就是一個最佳案例

你呢?如果你可以改變C語言的某一個部分,你會想改變什麼?又為什麼?

編譯:Judith Cheng

(參考原文: Fixing C,by Jack Ganssle;本文作者為The Ganssle Group總工程師)