ACM的通信

致编辑的信

让责任承担者买单

CACM人员
ACM通讯，2016年1月，第59卷第1期，第8-9页
10.1145 / 2851198
评论

在他给编辑的信《当Autonomous失败时，谁来买单?》(2015年11月)，在Keith Kirkpatrick的新闻故事《无人驾驶汽车的道德挑战》(2015年8月)上，Hans Grünberger抨击了我关于设立伦理审查委员会的提议(http://for.tn/1NHHU1s)，暗示我打算通过这些委员会的认证作为一种机制，以保护软件公司和汽车制造商免受不可避免的财产损失、伤害和死亡的责任，即使是设计最好的自动驾驶汽车也会导致这些损失。这错误地描述了我的信念和我的建议。

我不打算(现在也不打算)把这样的板子当作挡箭牌。相反，软件公司和汽车制造商应该为其产品的大大小小的意外事故负责(然后他们将相应地定价)。但是，必要的伦理决策要么由商业利益集团在真空中做出，就像今天普遍发生的那样，要么找到一种方法，将公众利益和专业知识纳入其中，就像我提议的机制——由制造商、律师、伦理学家和政府实体组成的审查委员会。同样地，在相关领域——这些汽车的基本安全——政府监管是必要的。http://huff.to/1MWByHW)，我对此作了证明(http://bit.ly/1Rn2Wlt)在2015年1月加州机动车辆管理局之前，这可能让汽车制造商和出席的谷歌代表感到沮丧。

乔纳森·汉德尔，加州洛杉矶

回到顶部

从一个可靠的发布计划开始

在他们的专栏“会议应该和期刊相遇，在哪里?”“PACM”的建议”(2015年9月)，约瑟夫A.康斯坦和杰克W.戴维森提出了一个期刊系列，被称为ACM会议论文集，这将包括ACM最负盛名的会议记录的论文，认识到与期刊论文相比，一些人认为会议论文是二等的。该专栏支持这一提议，称许多科学家更喜欢参加会议，因为他们对研究的最新看法，而且期刊的限制(比如出版速度慢)不再困扰潜在的作者。因此，合并论文集和期刊似乎是平衡计算机科学界相互竞争的利益的一种自然方法。

---

请编写小而简单的代码块，让自己不必担心裸花括号。

---

相反，朝着这个方向迈出的第一步可能是，通过在从提交到发表或拒绝的修订和编辑过程中建立严格的截止日期，减少标志性CS期刊特有的过长的评估响应时间表。以我有限的经验来看，期刊出版速度慢确实仍然是一个问题。作者们往往只是因为更短、更确定的响应时间，才有动力把论文提交到会议上。如果这个假设是正确的，减少评估响应和编辑时间即使不能最终解决，也会在最初缓解Konstan和Davidson在提出PACM时概述的问题。

纳塔尔Patriciello马拉内罗,意大利

回到顶部

按住大括号，简化代码

A.弗兰克·阿克曼(Frank Ackerman)给编辑的信“禁止‘裸’牙套!”(2015年10月)，其实吓到我了。它所描述的问题是:代码块太长太复杂，甚至连专业程序员都难以确定哪个大括号关闭它们，这当然是一个问题，但提出的解决方案不会让代码变得更复杂。

在处理遗留代码时，维护者可以向长方法的闭大括号添加注释，如前所述，以帮助它们导航，但这在新代码中不应该是必要的。

现代代码编写技术鼓励使用小的、只有最小嵌套的块。参见Robert C. Martin的干净代码第三章(Prentice Hall, 2009)给出了很好的解释和理由。根据Martin和其他人的说法，一个跨越超过几行的函数或方法对于一个普通的程序员来说是难以快速吸收和理解的，特别是在一个更大的系统的上下文中，应该为了简单而重构。嵌套在两层以上的块将不适合一个简短的、可读的函数，因此应该进行重构以降低深度。遵循这些实践的程序员不可能丢失闭括号，也不需要标记它们。

我以阅读和尝试理解不必要的复杂代码为生，并遵循马丁的哲学。如果一个人写的代码复杂到需要标注闭大括号，那么标注这些大括号并不会使代码变得不那么复杂。

如果你是一名程序员，请编写小而简单的代码块，不必担心裸花括号。如果你的习惯太深，请不要鼓励别人养成，尤其是初学者。

杰米·黑尔，马卡姆，安大略省，加拿大

a . Frank Ackerman给编辑的信(2015年10月)建议用注释标记每个构造终止符，指出它终止了哪个构造。这一明智的实践在书中描述的设计技术中得到了进一步的发扬程序设计原则(学术出版社，1975)和论文《程序设计的建设性方法》(LNCS 44，施普林格，1976)。每个序列、选择和迭代控制构造都被命名。在开始标记和结束标记前加上名称，在选择中，给每个选项加上名称前缀。因此，Ackerman的编码示例可以扩展为以下框架:

这样的纪律不仅避免了简单的错误。正如阿克曼所暗示的，它还通过将代码与设计紧密结合来改进程序。

迈克尔•杰克逊，米尔顿·凯恩斯，英国

回到顶部

假设5%的专家型程序员

Jack Ring给编辑的信“给我5%精进的批判能力”(2015年6月)淡化了我之前在Michael Walfish和Andrew J. Blumberg的文章“验证计算而不重新执行它们”(2015年2月)中所提出的“缺失技能集的案例”(2015年4月)中的担忧。信中说，所有IT管理需要的是某种“……5%的员工处于专家评论家的水平……，这一数据没有任何参考资料支持。知道它的来源可能有助于我们理解让Ring得出这个特定百分比的演绎过程。信中进一步表示，公司需要“……批判性的态度和一个工具，告诉他们一个项目或多个项目的组合是否违反了既定规则……”这与最初的一点无关，即普遍缺乏有能力的专业程序员，而不是自动化工具的可用性。

实事求是地说，这封信的主张必须满足三个条件:“批判性态度”，这是没有人会反对的，尽管过度的批判性态度可能会潜在地导致一个组织的灭亡;一个工具;和“既定规则”。虽然用于正式验证的学术工具很容易获得，但隐含的假设是，对每种类型的软件项目来说，都有一组通用的既定规则。此外，这些规则与传统上由编译器、链接器或相关虚拟机执行的规则不同。如果能看到一个正式的证明来证明这个假设的规则集适用于所有软件项目，那就再好不过了。

如果这个原则确实不是通用的，而是特定于项目的，程序员将不得不从用户需求中发现并用一些正式的语言编写它们。只有在这一步之后，一个工具才能被用于正式的验证。而且，即使在工具能够识别错误之后，这个循环还会重新开始，程序员会纠正代码，重新验证，等等。所有这些活动都要花费时间和资源，而这些时间和资源总是有限的。这也证明了我在最初的信中提出的观点，即没有足够多的程序员具备编写高效且可验证的并行程序所需的技能。

因此，信中假设的工作环境可能涉及开发时间延长、预算膨胀和项目延迟，这些都是导致组织潜在失败的已知因素。大多数中小规模的软件公司无法承担这样的开发生命周期。据我所知，唯一可能维持这种生命周期的组织类型可能是学术机构、以研究为中心的企业，或者涉及实时或安全关键型应用程序的公司。因此，也许我们应该花时间重新评估和修订ACM/IEEE计算课程，以确保在这些领域训练的未来专家程序员的充足供应。

Muaz a Niazi伊斯兰堡,巴基斯坦

回到顶部

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

---

没有发现记录