ACM通信

BLOG@CACM

注释代码，考虑数据的瓶颈

埃德温·托雷斯、瓦利德·萨巴著
ACM通讯，2018年5月，第61卷第5期，第24-25页
10.1145 / 3193752
评论

http://bit.ly/2FgllP9
2018年2月26日

在计算机科学中，你被教导注释你的代码。当你学习一门新的语言时，你学习的是该语言中注释的语法。尽管编译器或解释器忽略程序中的所有注释，但是注释是有价值的。然而，最近有一种观点认为注释代码是不好的，你应该在你的程序中避免所有注释。在2013年的文章中无注释:为什么注释代码仍然是一个坏主意，彼得·沃格尔继续讨论。

那些认为注释代码是一个坏主意的人认为注释增加了不必要的维护;当代码更改时，还必须修改注释以保持它们同步。他们认为程序员有责任写出真正明显的代码，消除注释的需要。尽管这些都是避免注释代码的合理理由，但这些理由过于简单和笼统;评论是必要的原因有很多:

1. 不是所有的程序员都能写出真正明显的代码。刚开始编程的人只乐于写出正确的程序;他们仍在掌握这门手艺。即使是有经验的程序员也会写出草率的代码。程序就像指纹一样是唯一的，因此判断代码是否明显是一种主观的判断。
2. 评论太多可能会很乏味，但有些评论就像文章的标题和字幕;它们引导、提供上下文并传达整体意义。
3. 注释不仅仅用于代码;它们可以记录重要的程序信息，如作者、日期、许可证和版权细节。
4. 有些编程语言很神秘，比如谷歌眼镜的编程语言。这个示例程序(http://esolangs.org/wiki/Glass#Fibonacci_sequence)很难破译，但打印斐波那契数列。你明白这个项目的意义了吗?也许可以用一种更明显的方式来写，但注释可以传达它的意思。
5. 一些公司要求员工注释他们的代码。谷歌的编程风格指南指定了如何用Java、JavaScript和c++等编程语言编写注释。
6. 专用注释允许javadoc、JSDoc和apiDoc等工具为程序生成专业、全面和一致的文档。
7. 注释可以是未来工作的占位符，是为大型程序创建大纲的有用方法。Eclipse集成开发环境(IDE)在生成一个主方法时创建一个TODO注释，它提醒添加程序的开始代码。

评论可能是乏味的或压倒性的，但在许多情况下是有价值的。即使你认为你写了明显的代码，几个月或几年后再读你的代码;这对你来说还是显而易见的吗，或者你想要评论吗?

回到顶部

评论

正如沃德·坎宁安(Ward Cunningham)指出的那样，评论的一个关键特征是关于叙述的。重要的是要区分代码*用于*什么，而不仅仅是它是什么，以及关键的假设和约束可能是什么。了解需求是什么是很有价值的，而代码很少是需求的替代品。
丹尼斯·汉密尔顿

丹尼斯:说得好。有时，您只需要对代码进行快速概述，而不需要花费时间进行跟踪。注释在这里有帮助，假设它们是正确的。
埃德温·托雷斯

我们在很多事情上意见一致。例如，我应该指出，我反对的是“在”代码中的注释，而不是在方法开头的注释，这些注释包括作者的名字、创建的日期等等(尽管通常，源代码控制可以自动完成这些工作)。

我也完全同意你的观点，在一个方法的开头，代码应该描述这个方法的“目的”是什么，为什么这个方法存在或被编写。这是即使是非常明显的代码也无法传达的内容。在最好的情况下，真正明显的代码可以传达代码“如何”做什么(尽管方法的名称有时可以帮助说明这段代码“用于”什么)。

我们甚至同意需要注释神秘的代码。但是，我建议不应该首先通过编写注释来解决这个问题:应该首先通过编写明显的代码来解决这个问题。如果斐波那契生成器中存在错误或者需要增强它，那么清除代码将帮助您找到错误或以注释无法做到的方式增强代码。在这种情况下，我建议我们考虑一个注释，作为原程序员对下一个程序员的道歉:“我已经尽了最大努力，但是由于各种原因，我仍然得到了这段不幸的代码。这是我能帮上忙的。”

我喜欢将注释作为标题来指导程序员编写代码的想法。作为一名兼职技术作家，这对我尤其有吸引力。当然，我将建议这些注释(如标题)的长度只有两到三个单词，并且可能会证明该方法应该被重构为几个方法，它们的名称反映了这些标题。但是，在很多情况下，我认为这有点过头了。

事实上，我只在一个地方不同意你的观点:一个不会写明显代码的程序员，出于某种原因，能够写出(a)明显的、(b)准确的和(c)完整的注释。毕竟，我们雇佣程序员是看他们写代码的能力，而不是看他们作为技术写手的能力。如果注释不准确，那么套用“编程风格的元素”，代码及其注释提供了处理逻辑的两种描述。如果他们不同意，只有代码是正确的。在这一点上，超出描述方法用途的代码创建了修复注释以使它们与代码保持一致的维护负担。程序员已经够忙的了。
彼得·沃格尔

我的目标是强调一些额外的评论需求。我同意“代码不会说谎”的说法。此外，太多的注释会让人不知所措，让人分心。我发现有趣的是，关于评论的讨论甚至存在于今天。谁能想到呢?
埃德温·托雷斯

这是一个很好的评论理由列表，我想再加上一个:对代码作者*您*来说很明显的东西，可能对读者*我*来说并不明显。如果你在上个星期一直在做你正在构建的功能，那么你已经花了那一周的时间来构建问题领域的那个区域的心理模型，并将其映射到软件系统上。我没有那种模型。开发人员应该试着去理解那些了解软件，但对这个问题不熟悉的开发人员，并帮助他们提高对这个问题的理解。
格雷厄姆·李

格雷厄姆:说得好。我最早学到的编程经验之一是，改变别人的程序比创建自己的程序要难得多。如果有效地使用，注释可以在这里提供帮助。
埃德温·托雷斯

回到顶部

Walid Saba:我们刚刚用“数据瓶颈”取代了“知识瓶颈”吗?

http://bit.ly/2tdSHfS
2018年2月26日

20世纪90年代初，定量和数据驱动的革命掀起了人工智能(AI)的风暴，其背后的主要原因之一是符号(逻辑)系统的脆弱性以及它们对精心设计的规则的永无止境的需求。基本原理是知识的获取瓶颈在探索建立智能系统的过程中。新的cliché?让系统通过处理尽可能多的数据来“发现”逻辑/规则。通过强大的机器学习技术，系统将“发现”概率分布函数的近似值，并将“学习”数据是什么，它意味着什么，并将为以后的任何新的输入做好准备。这一切听起来都不错;事实上，好得令人难以置信。

尽管这种范式存在哲学问题(首先，归纳法在数学归纳法之外并不是一种合理的推理方法)，但在实践中，避免知识获取瓶颈似乎并没有带来任何净收益。在数据科学的世界里，似乎数据科学家花了超过一半的时间不是在科学上(模型、算法、推理等)，而是在准备、清理、按摩，并确保数据准备好被推到数据分析机器上——不管这个机器是SVM、深度神经网络还是其他什么。

一些研究表明，数据科学家花费了近80%的时间来准备数据，即使在完成了这个乏味而耗时的过程之后，数据“科学家”通常会将意想不到的结果归咎于数据的不充分，并进行另一个长期的数据收集、数据清理、转换、按摩等迭代。考虑到数据科学家是当今IT行业收入最高的专业人士之一，他们80%的时间都花在清理和准备进入地狱的数据上，这难道不应该引起一些人的不满，至少应该引起一些人的不满吗?

这样的技术，即使经过漫长、繁琐的数据清理和数据准备过程，仍然是脆弱的。这些模型可能会被相似的数据所欺骗，但这将导致这些模型错误地对它们进行分类。对抗数据的问题得到了太多的关注，但目前还没有解决方案。已经证明，任何机器学习模型都可以被对抗性数据(无论是图像、音频信号还是文本)攻击，并可以让分类器做出决定攻击者想要的任何分类通常通过改变一个像素、一个字符或一个音频信号来改变，否则人类是不会注意到的。

也许不是我们想要的所有东西都在数据分布中?也许我们正处于(数据)狂热之中?也许我们对知识获取瓶颈的反应有点过头了?

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.

---

没有找到条目