我忍不住写了这份代码指南
|
用读的出来的单词 如果名称读不出来，那么讨论的时候就会像个傻鸟 使用方便搜索的命名 名字长短应与其作用域大小相对应 避免思维映射 比如在代码中写一个temp，那么读者就得每次看到这个单词的时候翻译成其真正的意义 注释 有表达力的代码是无需注释的。 The proper use of comments is to compensate for our failure to express ourself in code. 注释的适当作用在于弥补我们用代码表达意图时遇到的失败，这听起来让人沮丧，但事实确实如此。The truth is in the code, 注释只是二手信息，二者的不同步或者不等价是注释的最大问题。
书中给出了一个非常形象的例子来展示：用代码来阐述，而非注释 层级来展示代码的意图。 当然，也不能因噎废食，书中指出了以下一些情况属于好的注释
放大看似不合理之物的重要性 其中个人最赞同的是第2点和第5点，做什么很容易通过命名表达，但为什么要这么做则并不直观，特别涉及到专业知识、算法的时候。另外，有些第一感觉“不那么优雅”的代码，也许有其特殊愿意，那么这样的代码就应该加上注释，说明为什么要这样，比如为了提升关键路径的性能，可能会牺牲部分代码的可读性。 最坏的注释就是过时或者错误的注释，这对于代码的维护者（也许就是几个月后的自己）是巨大的伤害，可惜除了code review，并没有简单易行的方法来保证代码与注释的同步。 函数 函数的单一职责 一个函数应该只做一件事，这件事应该能通过函数名就能清晰的展示。判断方法很简单：看看函数是否还能再拆出一个函数。
函数要么做什么do_sth, 要么查询什么query_sth。最恶心的就是函数名表示只会query_sth, 但事实上却会do_sth, 这使得函数产生了副作用。比如书中的例子 （编辑：唐山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
