Editing Coding habits to avoid

避免的 coding 習慣
* 避免使用簡化的的變數名稱，例如 $sd 或 $d 也許一開始還會記得，但是過一陣子就會忘記這是什麼

* 避免使用過於籠統的變數名稱，例如 $data 或 $file_path 「這個 $data 裡面放的是什麼？」當變數名稱不夠明確時，三個月後連自己都會忘記當初的設計。使用具描述性的變數名稱，可以讓程式碼自我說明，減少日後維護的困擾。

** $data 可能代表任何資料，過一陣子就會忘記裡面存的是什麼內容。建議改成更具體的名稱，例如: (1) $user_data：使用者資料、(2) $order_list：訂單清單、(3) $product_info：產品資訊
** $file_path 建議改成能表達檔案用途的名稱，例如: (1) $config_file_path：設定檔路徑、(2) $upload_image_path：上傳圖片路徑

* 重複複製貼上的內容，但是內容可能常被其他使用者更改，導致內容更新困難，需要修改多處的程式碼

* 絕對路徑或絕對網址寫死在程式碼內，導致日後移機或對外公開網站服務時，需要修改多處的程式碼

** 存取檔案時將完整路徑，例如 {{kbd | key= <nowiki>D:/AppServ/www/abc.csv</nowiki>}} 寫死在程式碼內。可以改成使用相對路徑，例如 {{kbd | key= <nowiki>__DIR__</nowiki>}}<ref>[https://www.php.net/manual/en/language.constants.magic.php PHP: Magic constants - Manual]</ref> 代表檔案所在的資料夾。
** 將測試網址 (127.0.0.1 或 localhost) 寫死在程式碼內

* 容易閱讀的錯誤訊息:除了 500 Error ，如果可以讓使用者自行處理，建議改成容易閱讀的錯誤訊息。

* 「你那邊不能跑嗎？可是在我這邊跑起來是沒問題的。」通常問題出在開發者與程式執行的環境不同，需要檢查是否程式版本環境、相依套件版本。如果是網頁程式，則需要進一步檢查瀏覽器的快取與擴充套件是否衝突。

* 「昨天下班前明明還好的啊，怎麼今天我還沒動它就壞了。」使用 Docker 重新建立執行環境，進行測試。

* 「程式一直找不到問題出在哪裡？」請搜尋單元測試。將複雜的資訊系統拆解成可測試的模組。

* 「Bug 不知道問題原因在那裡，但是這一版改完就可以動了。」請搜尋單元測試。

[[Category: Programming]]