Yukuan's Blog: font

接連多日的年假已接近尾聲，吃吃喝喝之餘，很自然地就想到一個跟吃喝有關的練習。雖然年假前在公司搞的相框產品確實用到各式 UI 選單（menu），但我在這裡要聊的是名副其實的菜單（menu）。

為了製作精美的菜單，我用 Google 搜來幾張食物的圖片準備用作底圖，除了一張用作食物主選單底圖外，其餘三張分別用作飲料類、水果類和蔬菜類等用途。

考慮到要製作的菜單不只一張，且每張菜單的內容會一直修改，所以我不打算用繪圖軟體繪製菜單，這個重任當然要照慣例，委託給爬說語。要執行這支程式，必須先以 YAML 語法，利用文字編輯器寫下菜單的內容及呈現方式，存成 menu.yaml 。程式執行時會自動讀進這個描述檔，然後描繪出期望的菜單來。例如說，有張菜單長成這樣：

這是一張飲料類的菜單，它有 Coffee, Juice, Soda Water, Tea 等選項，要產生這張菜單， menu.yaml 這個純文字檔就要列出飲料類菜單的內容：

title: '==   Drink   =='
items:
    - Coffee
    - Juice
    - Soda Water
    - Tea

除了填寫菜單的內容外，還要填寫菜單的呈現方式：

style:  # Style of title, items, focused items
    font: [cour.ttf, 24]
    title: {color: clYellow}
    items: {color: clWhite}

當然不能忘記告知從 Google 那搜來的底圖：

basemap:
    dim: [320, 240]  # dimensions of width and height
    color: clWhite
    image: drink.jpg
    type: image  # {color, image}

完整描述請參閱 menu.yaml 。程式請參閱 MenuShow.py。

William 在〈軟體的庖丁解牛能力〉中引述了 Peopleware 第 29 章的話：

工作流程愈是獲得改善，工作內容就愈艱難……一、沒有被替除掉的工作，就是更加知識密集、需要更多技術與經驗……二、經過改善的工作流程，讓你能夠面對更艱難挑戰，而你也會面對這些挑戰……

當工作流程獲得實際改善，我們也同時需要更多更有能力、更有經驗的員工。

William 後來特地在〈工作流程愈是獲得改善，工作內容就愈艱難〉附上了這段話的原文，有興趣可以自行參閱。

這裡我就不談工作流程了，只談談作為一門專業，程式設計有哪些值得我們關注的小細節：

Coding Style

這裡不捲入哪種 Coding Style 較好的爭論。只強調一點，選擇特定的 Coding Style ，是為了要把程式的邏輯結構強調出來，使其看起來條理分明。並不是為了排版的好看與否。

這方面議題，就我所知，寫得最好的，出現在《Code Complete》的第十八章。裡面列出各種 coding style ，由程式的縮排一直到註解的寫法，都有各種例子，並以程式的「邏輯結構」被凸顯的情形，逐一進行比較。

Editor

好的文字編輯工具是很重要的，諸如：可以讓人自訂的 Syntax Highlighting、自訂字型，自訂背景顏色、自動縮排（auto-indent）、多檔管理、Project based 的 Find/Replace/Regular Expression、Auto-Completion，甚至 Code Folding, Refactoring 的支援等，都要仔細評估，找套合用的。

作為 coding 的 Editor ，新版的 UltraEdit 用起來很順手，這裡強烈推薦。

此外，作為跨平台及 open source 軟體， CodeBlocks 是一套非常符合我胃口的 C/C++ IDE ，雖然還有些不足的地方，但其改善的速度也是令人印象深刻。

Font

專業的程式設計師，不會放過任何可以改善其 coding 方式的機會，連 coding 用的字型，也要挑剔一下：我們選用的字型，要能方便長期閱讀 code ，一些易發生混淆的字元，諸如大寫的 O 和數字 0 間；數字 1 、大寫 I ，及小寫 L 間等，也要能很明確區分。甚至括號在顯示時也要作特別的強調。

好的 coding 字型，還要允許我們清晰地在同一個畫面閱讀更多行的 code 。這裡強烈推薦在 Proggy fonts 中，選一套來用。此外，〈Programming Fonts〉中也有相關的介紹。

Once and Only Once

Once and Only Once 是要我們剔除重複的程式片段，重複的邏輯要合併，重複的敘述要改寫，多餘的變數要刪除。重複不但顯得累贅，在修改時還容易發生遺漏、不一致的情形。要真正作好這點，其實就是要極力找出軟體系統的模式，其精神是「尋找模式，並反覆利用這些模式」

Unit Test Framework

如果還沒想清楚如何測試某段 code ，那就不要去編寫它。把測試及比對結果的工作，交給電腦來執行，是 Unit Test Framework 最大的用意。花些時間，找個所用語言及編程環境適用的 Unit Test Framework 是非常划算的投資。如果你在找 Embedded Systems 的 Unit Test Framework ，也許可以參閱拙作〈An Array Implementation of Queue〉中的例子。

Documentation

講起 Documentation ，就不得不提提高德納先生極為推崇的 Literate Programming 。這是種以寫文件為主，coding 為輔的程式設計方式。其背後的想法是基於，程式主要是寫給人看的，而非只為了給電腦執行。Literate Programming 的 code 穿插在文件段落間，要餵給電腦前，再用工具把 code 抽取出來，交給編譯器處理。

不過 Literate Programming 也只有高德納那樣的學院派高手，才能玩得盡興。像我這種在街上混吃的，還是較適合寫 code 為主，文件為輔的方式。這種作法的精神是，code 本身就要寫得能讓專業程式員很容易閱讀，然後再加上意圖性的註解，使其趨於完善。

像 doxygen 這樣的工具，讓我們在註解時，使用標準化的標記，然後再由程式源碼中，抽出特定註解，作為說明文件。

Version Control

想起學生時代，最常使用的 version control 方式，就是在 project 目錄下建立 /v0, /v1, /v2... 的子目錄，或者乾脆將整個 project 給它 zip 起來，然後在壓縮檔名附加版號及日期。這方法用於個人開發、幾千行以內的小規模程式，還算堪用。

後來接觸了 open source 的東西，所以 CVS 用了好一陣子。現在也不能免俗地，改用 Subversion 。如果你還沒選定適用的 Version Control Tools ，這裡推薦 Subversion，其 Windows 下的 Client, TortoiseSVN 當然也不容錯過。