- 2020-01-13什么时候开始 进入正题呀，前奏太长了
作者回复: 先从第一篇开始就是正题啊 😂 前面的比后面的更重要呢 建议你回过头去再看下前几篇文章
4 15 
2020-01-13课堂讨论：
1. 关于 isValidPassword() 可读性优化： 示例代码中的单行注释已经把验证规则清楚列明，但是必须打开源代码才能看见。我认为可以在函数声明处使用文档注释（即多行注释）对规则进行描述，这样函数的使用者借助 IDE 的代码提示功能就能看到具体的规则，同时也为用工具生成的项目文档提供注释。
2. 关于注释用中文还是英文的问题：对于团队开发，如果有外国人当然要用英文；但是如果只有中国人，我认为最好用中文。首先是每个人的外语水平不一，外语水平好的看到别人的语法错误甚至连单词都拼错，真的很影响心情。对于外语水平不太好的，使用外语写注释不友好且心理压力大，甚至回过头再看都不知道自己当初想表达什么。团队中最重要的是相互合作和最后上线的产品，而不是相互折磨，如果要求使用英文注释会推高沟通成本，那就得不偿失。对于个人项目，选择中英注释均可，但应统一风格。我认为注释只是一个工具，用于降低沟通成本和提醒自己写代码时的思维逻辑和一些关键步骤，但是切不要对这个工具有过高的期望，譬如提高个人甚至团队的外语水平。展开 15
2020-01-13编程的两大难题：并发和起名 3 6
2020-01-13There are only two hard things in Computer Science: cache invalidation and naming things.-- Phil Karlton
命名达意、准确：
不知道如何命名，推荐：Codelf(变量命名神器) https://unbug.github.io/codelf/
Search over projects from Github, Bitbucket, Google Code, Codeplex, Sourceforge, Fedora Project, GitLab to find real-world usage variable names.
关于注释语言：
公司的项目看项目要求（中英文都可以）
自己的个人项目一定要用英文，因为一开始我就考虑到要做国际化的项目（目标是全球用户）。
如何写注释可以多看看JDK源码中的注释，能够学到很多东西。展开 1 5
2020-01-13设计模式_31
# 作业
1. 可能是为了举例吧，我认为这里的4个注释都是多余的。这些注释并没有比代码更简洁，阅读注释与阅读代码的理解成本是一样的。
2. 注释用中文还是英文，工作中一定要看团队成员的情况。个人推荐全部使用英文，从成长的角度来看，这有助于加强程序员的英文读写能力，而这个能力是非常有价值的。
# 感想
写代码的时候，我常常问自己一个问题。如果后面有一个人要接收我的项目，他会不会骂我。。。我就暗自骂过很多人。。。
所以在某些与常规逻辑明显不同的地方，我的注释量甚至多于代码量。当然注释也不是越多越好。展开 5
2020-01-13所谓无规矩不成方圆。同样我们在做一些事情的时候是有套路可寻的。在写代码的时候我们也需要遵循一些前人总结好的规范，使得自己写代码更具有可读性，可维护性。
今天从这篇文章中学到了关于命名和注释的一些见解。关于命名，以前自己会犯的一个错是将拼音和英文会混在一起用，现在想想估计太年轻，命名搞得不伦不类。现在已经改了，一直督促自己用英文。命名的原则是准确达意，在平时的开发中都我都是尽量使用完整的单词，即使这样命名会很长，但是能够清楚的表达。文章中说的借助上下文来简化属性、函数的命名自己没有实践过。
关于注释，在自己的开发习惯中对于类和方法都是要写注释的，但是自己对注释的理解比较浅，只是写了做什么。并没有从文中提到的“做什么、为什么、怎么做”这三个维度去考虑。对于一些非常简单的方法，如只有几行，一眼就能读懂其要表达的逻辑的，我一般不写注释。对于注释的维护的确是有一定的成本。某些时刻一个逻辑复杂的方法有变动，可能会忘记同步修改其对应的注释，就会导致之后的阅读理解有误导倾向。个人觉得类、方法的注释很重要，以前遇到自己不懂的，我都会到某度上去查，发现往往很多搜索结果解释的不够准确，常常会误导我。后面我几乎都是通过阅读官方文档来学习，如通过阅读JDK中JavaDoc的文档就能准确的理解某个函数能做什么，该怎么用。
关于注释该用英文还是中文这个问题，个人觉得用中文可能比较好，因为大家母语都是中文，你不能按照自己的标准来想别人也能读懂你写的英文。除非是做国际化项目以及所在团队能接受注释全用英文那自然更好。展开 3
2020-01-13在 User 类这样一个上下文中，我们没有在成员变量的命名中重复添加“user”这样一个前缀单词，而是直接命名为 name、password、avatarUrl。
但示例代码好像都带了 user 前缀？作者回复: 这节课里的代码都没带吧
1 3
2020-01-22最近在看《编写可读代码的艺术》，里面有两章就是在讲本文的主题，也推荐给大家 1- 2020-01-17全是细节，感觉要培养自己的代码意识 1
2020-01-15
1. isValidPasword函数里面代码有重复逻辑check if password contains only lowercase characters可以被 check if password contains only a~z,0~9,dot包含， 所以可以去掉check lowcase char这个判断
2. 关于英文和中文注释哪个好，取决于你的代码将来要给谁看。国内的开源framework要走向世界，就需要程序员添加英文注释。 1
2020-01-14注释推荐使用英文，只有一个要求，英文水平要过硬。如果英文水平不够，写英文注释没什么收益。 1
2020-01-13不够看啊，每天很快就看完了。 2 1
2020-01-13我司接口类前面有个I，实现类后面也有imlp。。。
思考题1 比如判空那个注释就没必要了。我感觉是个人就应该知道是啥意思吧。
思考题2 个人认为，如果英语水平过关的，可以写英文注释，但是英语三脚猫那种，你还是老老实实写中文吧。真人真事，我刚工作那会，做个手机维修得项目，有个后台服务叫做上门服务。然后我那睿智同事就写了个ondoorService，我看到了之后。。。Are you kidding me？展开 4 1
2020-01-13注释肯定中文啊。毕竟母语。 1
2020-01-131. 可以考虑合并一部分简单的条件表达式，并且分拆过于复杂的条件表达式。
2.注释的语言可以考虑这段代码的维护者的情况，如果中国人外国人都有那么可以考虑使用双语：） 1
2020-02-09命名和注释体现了一个程序员的品味，说几种不好的命名吧：
1 英文单词拼写错误，这个特别影响可读性
2 函数名不明确，比如get方法返回空值，实际上是在函数内部update了变量
3 非驼峰
4 拼音式命名
如果原作者在这方面不动脑子，读代码的人就特别费脑子展开
2020-02-08准备面试落了几堂课，补上
1.已经表明是密码检验了，但是检验什么内容，例子可以在函数注释中体现
2.能用英文讲清楚最好，不能用也不强求，我觉得都可以- 2020-01-22命名还要具体，不能过于抽象。比如 flag，type，在没有上下文的前提下，根本不知道在干嘛。
2020-01-211.isValidPassword函数命名没有问题，那么在注释的时候，就要特别注释写出，符合哪些规则的才算有效的密码，这种很重要！
2.关于注释使用中文还是英文的，我觉得对于业务逻辑开发而言，使用中文更能协作团队开发，（当然指团队内是国内的业务）
2020-01-20思考题：
1. 可以把校验密码的规则统一写在函数注视里，函数里面的代码可以不写注释了。好处是一目了然，不看代码也知道密码合法与否。
2. 用英文。免去了乱吗问题，而且惯例是用英文写。如果需要自动生成国际化API文档的，可以加个locale注解，中英文各写一次。