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

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

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

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

*各種程式語言的使用情況統計*

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

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

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

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

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

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

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

編譯：Judith Cheng

(參考原文： Fixing C，by Jack Ganssle；本文作者為The Ganssle Group總工程師)

活動簡介

未來寬能隙半導體元件會在哪些應用成為主流？元件供應商又會開發出哪些新的應用寬能隙元件的電路架構，以協助電力系統開發商進一步簡化設計複雜度、提升系統整體效率？TechTaipei「寬能隙元件市場與技術發展研討會」將邀請寬能隙半導體的關鍵供應商一一為與會者解惑。

贊助廠商

立即報名