這週的題目是：「檢查」的相關動詞。 * 如何命名「檢查」功能？ * Check, Test, Verify, Validate 有什麼不一樣？ --- * Google 簡報 https://bit.ly/31UiEPK * Facebook 相簿 https://bit.ly/31NqsCU * GitHub 討論 https://bit.ly/321ResR --- # 先說結論 * 如果不確定該用哪個動詞，就用 *Check* --- # 所謂「檢查」這個動作 相對於模糊邏輯 (fuzzy logic)，我們在寫程式時多半使用 古典邏輯 (classical logic)，也就是以「真、假」二元的方式來表示邏輯、進行 運算；例如，以下程序： 1. 如果 1. 「使用者有讀取權限」為真 2. 就 1. 傳回資料 3. 否則 1. 丟出錯誤 在我們寫的程式中，常常需要「檢查」程式邏輯模型的狀態，然後做出判斷，決定 程式下一步的行為。 這就是這週的題目：「檢查」的相關動詞。 --- # 檢查： Check Check 可說是最萬用的「檢查」動詞，它可以用來： * 檢查「有無」 * Windows 更新 * 讀寫權限 * 新 email * 檢查「對錯」 * 拼字、文法 * 檢查「狀態、品質」 * 網路連線 有無 連上 * 硬碟空間 是否 足夠 幾乎什麼都可以來 *check* 一下。 如果不確定要用什麼動詞來表達 * 檢查有無、對錯、是否 * 檢查系統狀態，做出判斷，傳回詳細資訊 的動作，用 check 大概不會有錯。 XD 接下來，以 check 為基準來比較幾個「檢查」相關動詞在語意上的特點。 --- # 「檢查 + 後續動作」的動詞 相對於單純只執行「檢查」的 check，assert 與 ensure 分別代表以下兩個常用 的「檢查 + 後續動作」程式結構。 ## Assert 「檢查之後，若系統不滿足條件，丟出錯誤」。 1. 檢查「某條件Ｃ」 2. 若 1. 「某條件Ｃ」為假 3. 就 1. 丟出錯誤 ## Ensure 「檢查之後，若系統不滿足條件，採取行動確保系統狀態合乎條件」。 1. 檢查「某條件Ｃ」 2. 若 1. 「某條件Ｃ」為假 3. 就 1. 採取行動以確保系統狀態合乎「某條件Ｃ」的要求 --- # 重視實驗的「測試 (test)」動詞 * 檢查 (check) 偏向「從系統讀取資訊來做出判斷、回報結果」 * 測試 (test) 偏向「與系統互動並觀察其反應來做出判斷、回報結果」 以「有無讀寫權限」為例： * 檢查 (check) 可能會拿著目前使用者的身分符記 (token) ，詢問作業系統該使 用者是否有讀寫權限，然後回傳檢查結果。 * 測試 (test) 可能會以目前使用者的權限，直接去試試看能否真的執行讀寫動作 ，然後回傳測試結果。 --- # 重視預期正確答案的「驗證」動詞 相對於檢查(check) ，「驗證」偏向於「讀取資訊，與預期的正確答案比對，回報 結果或丟出錯誤」。 以「 email 格式正確與否」為例， validate 比 check 更能強調「驗證是否合乎 規範標準」。 以「使用者密碼正確與否」為例， verify 比 check 更能強調「驗證是否合乎已 知的正確答案」。 --- # 確認 (confirm) vs. 驗證 (verify) 確認 (confirm) 與驗證 (verify) 兩者都可以用來檢查「事情是否準確、真實」 ，但它們在語意上有微妙的差異： * 確認 (confirm) 傾向「確定想法；消除疑慮、不確定性」。 * 在前端設計，會以 confirm 或 OK 來讓使用者「確認」執行它的選擇；而不 常用 verify 。 * 在日常會話，會以 confirm 作為動詞來「確認」行程；而不常用 verify 。 * 驗證 (verify) 傾向「取得資訊、進行實驗來判斷事情是否正確」。 * 在前端設計，會以 verify 來提示使用者「驗證」它的手機。 * 在後端設計，會以 verify 來命名「檢查事情是否準確、真實」的方法；而不 常用 confirm 。 --- # 其它情境 在某些相對少見的情境下，「檢查」有它的習慣用字，例如： * authenticate : 檢查使用者身分真偽 * scan : 大範圍檢查；掃描 * ping : 檢查遠端伺服器、服務的狀態 * analyze : 檢查系統行為現象的本質；分析 * audit : 全面嚴謹地檢查系統的行為；審察 * diagnose : 檢查問題的原因；診察 * inspect : 檢查是否滿足某種標準；稽察 其它還有 examine、investigate、review 等字；在程式碼中相對地罕見，在文書 或註解中比較常見。 --- # 結語 一週探索一個題目，逐漸把寫程式會用到的英文知識整理起來；每個人都是從零開 始學起的，我也從讀者提問中學到了很多 :) 如果你在寫程式時有遇到英文表達上的問題，歡迎留言討論，或到《程式英文》 GitHub 討論區 https://bit.ly/321ResR 提問。 這可以幫助我把這個列表整理的更完善，謝謝 :) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 136.56.13.184 (美國) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1597382427.A.19A.html 同意；長期來說會想往 HTML / GitHub Pages 的方向前進；方便閱讀、檢索、製 作、協作。 謝謝鼓勵 :) 謝謝各位的欣賞 :) ※ 編輯: AmosYang (136.56.13.184 美國), 08/15/2020 12:40:07 謝謝 :) 是的，有打算做 CRUD 。 目前有一篇『如何命名「刪除」功能？』，可以參考以下連結： * #1V8-skH9 (Soft_Job) * https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1596190126.A.449.html Ｃ、Ｒ、Ｕ的部分還沒開始寫，但有開項目追蹤 :) * Ｃ: https://github.com/EngTW/English-for-Programmers/issues/28 * Ｒ: https://github.com/EngTW/English-for-Programmers/issues/29 * Ｕ: https://github.com/EngTW/English-for-Programmers/issues/30 ※ 編輯: AmosYang (136.56.13.184 美國), 08/16/2020 20:54:18 ※ 編輯: AmosYang (136.56.13.184 美國), 08/16/2020 20:59:45 很有意思的題目 :) 能否談談你覺得「寫 commit message 時，多半卡在哪裡？」；例如說，句型、文 法、選字？ 或著，若能談談「讓你覺得卡住的案例」，也能幫助我們找到解決問題的方向。 --- 可以在這裡推文討論、 PTT 站內信 、或 Facebook/Twitter 私訊都可以 :) * https://www.facebook.com/twy30 * https://twitter.com/twy30 ※ 編輯: AmosYang (136.56.13.184 美國), 08/17/2020 05:46:29 謝謝各位的欣賞 :) ※ 編輯: AmosYang (136.56.13.184 美國), 08/21/2020 12:40:58 謝謝 :) 謝謝你的欣賞 :) 有沒有興趣描述一下你遇到的困境？或許我可以幫上忙 :) ※ 編輯: AmosYang (136.56.13.184 美國), 08/29/2020 07:47:32 謝謝 :) ※ 編輯: AmosYang (136.56.13.184 美國), 09/04/2020 12:13:48