-
注释确实有它的用途，但在大多数情况下，程序员滥用注释，我反对代码之间的注释，我认为注释应该独立于代码——通常称为文档。
请看下面的代码部分。
复制代码代码如下所示：
/ / / *静态市场/ checkout.js
创建orzfly 2014.7.2
2014.7.29更新jysperm：fixbugs
待办事项：这段代码太多的注释和需要被删除，jysperm
* /
无功raw_products =请求查询{ }等级产品的分裂（'，'）；
一系列货物
var产品= }
每个参数过滤器
对于（var i = 0，我的<< raw_products.length，i++）{
如果（！raw_products {我}）
返回；
数据出现在前面。
如果（！我raw_products { }。修剪（））
返回
* 2014.7.22：现在可以使用非数字ID。
跳过非数字条目
如果（isnan（raw_products {我}。修剪（）ToFixed（））））
返回；
* /
Products.push（raw_products {我}。修剪（）ToFixed（））；
}
总金额。
var总和= 0；
每种商品的货币数计算总数。
对于（var i = 0，我的<< products.length，i++）{
从数据库中检查商品信息
VaR数据= db.product.byid（产品{我}）；
谁将写关于待办事项：没有检查货物
这个数字加在货币/货物的总价格中。
data.price总和=；
}
你花在阅读评论的一半以上的时间，这就是生命的东西浪费，每个代码中的注释，代码会——即使读者了解一个音符传达精神增加阅读成本；也会增加维护成本：对人的修改代码与注释一起改变，你不知道他会不会这样做。
因此，只有在必要的情况下，才应该添加注释，并且简明明了。注释不应该解释一段代码在做什么，因为这是每一个合格的程序员都应该知道的，但为什么我们要解释这段代码。
这导致了一些不应该添加的明显注释：
应该由版本控制系统记录的信息、对代码的注释和待办事项。那不是很重要。
代码不是全部。如果一个项目是可靠的，它应该有自己的版本控制系统。除了记录代码差异之外，它还应该具有工作表和发布功能。
读代码的人通常不需要知道程序员之间的敌意。他们常常不在乎这段代码的历史。他们只把代码拖走。
Discarded code
删除的代码应该删除，这会影响阅读，而且它们通常很长。
在大多数情况下，放弃的代码将不再被使用，即使只有少数情况下，您也可以从版本控制系统中找到它们。
变量和函数名的解释
显然，在这种情况下，您需要一个更合适的名称。如果标识符具有较小的函数，则可以使用较长的名称来容纳更多信息。
例如，下面的：
产品应改为products_id
总和应改为total_amount
数据应改为product_record
语法的解释和明显的东西
例如，在上述商品货币总数中添加的价格中，a = a＝a是B的缩写，显然没有人知道。
也许有人愿意写这样的笔记来理清思路：
复制代码代码如下所示：
过滤参数：
删除ID空间
删除非数字标识
每一种商品流通：
检查记录/数据库
这个数字加到了货币{商品}的总价格中。
但记住在代码完成后删除它。
逻辑块的推广
例如，在上述情况下，过滤每个参数和计算每个商品的总金额，通常你不会抽象出逻辑。
复制代码代码如下所示：
要做的第一行25行代码
/然后有5行代码做B
这里有90行代码要做C
最后，有45行代码要做d
这将导致您需要一些注释来分割这四个部分。如果这四个部分都是函数调用，那么函数名本身就是逻辑的解释。读者可以很快地找到函数B，而不是搜索前25行中B的五行代码。
总之，我对这段代码的改进如下：
复制代码代码如下所示：
无功filterproductid =功能（raw_products_id）{
结果= { }
raw_products_id.foreach（功能（product_id）{）
如果（product_id和product_id.trim（））
products_id.push（product_id.trim（）ToFixed（））；
}）；
返回结果；
}；
无功getpriceofproduct =功能（ID）{
无功product_record = db.product.byid（产品{我}）；
如果（product_record）
返回product_record.price；
其他的
返回0；
}；
无功products_id = filterproductid（需求，查询{ }等级产品。分裂（'，'））；
无功tatol_amount = 0；
products_id.foreach（功能（product_id）{）
tatol_amount = getpriceofproduct（product_id）；
}）；
虽然我用一个虚构的、故意编好的代码来支持我的观点，但我相信在实际的项目中，我们也可以通过改进代码来减少注释，并且通常节省更多的时间和精力。