这周的题目是：「检查」的相关动词。 * 如何命名「检查」功能？ * 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/cn.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/cn.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