07 | 写好注释，真的是小菜一碟吗？

通过本篇学习，自己写的注释犯了两个错误一是提交了注释掉的测试代码和需求变更后不需要的代码，二是使用了TODO提醒自己，写完之后没有删除。 老师最后讲的五种风格，第三种风格和第四种风格有什么区别，只发现了颜色区别，其他的一样

留言区没有人讨论课后题，我抛砖引玉下。注释就像文中所说，准确、必要和清晰最重要，也就是说在不同的团队同一段代码的注释会不同，因为团队能力不同。这里我试着用比较完整的方式做一段注释，如果团队能力好，一些部分是可以省略的 import java.util.HashMap; import java.util.Map; class TwoSumSolution { /** * Given an array of integers, return indices of the two numbers * such that they add up to a specific target. */ public int[] twoSum(int[] nums, int target) { // init a map storing number and its index relation Map<Integer, Integer> map = new HashMap<>(); for (int i = 0; i < nums.length; i++) { // calculate the complement of current number int complement = target - nums[i]; // if map contains the complement, return complement directly, else update map with current number if (map.containsKey(complement)) { return new int[] { map.get(complement), i }; } map.put(nums[i], i); } // if the sum of any two numbers is not equal to the specific target, throw illegal argument exception throw new IllegalArgumentException("No two sum solution"); } }

作为前端人员买了这个专栏，收获也不少…… 能不能针对js讲一个课程。

在代码写TODO已成为团队的习惯

注释，以用户思维方式去写，准确、必要、清晰，真是不错的要求！学起来~

TODO还能写吗，有些待完成的事项依靠第三方或者还没想到更优的方案、标记todo提醒自己。如果不用这个标记，怎么快速定位？

「需要注意的是，如果文件有变更，记得更改版权信息的年份（比如上例中的 2018）。」 关于这个问题，我看很多开源项目在代码修改后中都没有修改日期。这是怎么回事呢？

如果一段代码不再需要，我会清理掉代码，而不会保留这个注释掉的代码块。 --我简直不能再同意了，我曾因为错误的注释代码而导致十几万的损失，我那时候测试分支特别喜欢用注释代码的方式，因为在一个文件甚至方法里复制并注释两下，是很快能达成一个分支的。这种错误的习惯一旦养成，隐患大大滴。正如您说的，这种情况应该使用版本控制。切换的时候，应该切换不同版本的文件。确定的分支如判断开发环境或生产环境，我喜欢用配置文件…应该，是受到前端套路的影响，你知道各种前端框架都喜欢isDev，我慢慢的…觉得好像还不错…

刚开始工作的时候，自己写了一段代码（没有什么注释），过来一段时间，自己维护的时候花了很多时间来读自己的代码。。。深刻明白了注释的重要性（虽然当时代码写的不好也有一部分原因）

建议英文 ，但是我们团队都是第二种，我们英语水平一般