Ruby 是否能够理解内联注释,例如:
my_array = ['first', /* 'second', */ 'third', 'fourth']
?
更新:
我问的不是 Ruby 中的 /* */ 是什么以及为什么我会收到错误,而是询问是否存在任何可用形式的内联注释。/* */ 仅作为我所知的内联注释的示例给出。
不,Ruby 没有内联注释。
这种风格的注释倾向于降低可读性,因为它们使代码更难理解。
在您的情况下,最好将您的数组项拆分为单独的行并注释掉一行。
my_array = ['first',
# 'second',
'third',
'fourth']
我只想补充一点,rdoc——Ruby 的内置文档构建器——可以利用代码中的注释来构建初始文档集。根据我在最近阅读中的理解,“Ruby 方式”建议您的代码应该是可读且不言自明的,但注释是在早期开发中构建文档的一种有价值且简单的方法,然后将项目发送到适当的文档团队。
关于内联注释,我的用例是在将它们提交到格式正确的源文件之前,我发现自己在 irb 中处理较长的单行代码。也许很多人不介意在他们的开发环境中使用换行符,但是由于我目前对工具集的了解有限,我发现重复以前的命令很乏味。我几乎可以肯定这是因为我没有掌握手头的工具,无论是 irb、pry 还是你有什么。目前,我将任何我希望在字符串对象中内联注释的代码包装起来,以后我必须通过删除字符串包装器来删除或“取消注释”。
要么接受,要么离开,但那是我的两分钱!继续红宝石!
附录:
阅读pry
文档是值得的!方法pry
绑定到每个对象,包括main
. 调用它会在当前提示中执行一个子 shell,允许您分析当前范围内的任何对象。它在任何上下文中都可用,包括main
pry 提示。再加上 Pry 中的amend-line
,edit
, hist
,play
命令,这满足了我对内联注释的渴望,尽管我仍然不知道 pry 中的任何功能会将先前的命令加载到当前提示符的输入中以进行编辑。
调用文本编辑器往往会分散我的注意力,不仅因为它从单个显示器(例如笔记本电脑)上的可见性中删除了 shell 缓冲区的内容,而且特别是因为它删除了所有有用的pry
选项卡完成和命令。我希望看到 pry 或另一个可以跨多行使用光标的 REPL,因为我仍然发现需要使用单行。
在你投反对票之前阅读整件事:)
老实说,您根本不应该使用注释,您的代码应该是不言自明的。
我知道这似乎离题了,但请听我说他们为什么不会在 Ruby 中实现这些评论。
我偶然发现了这个问题,因为我正在处理我们的客户丑陋的 API。处理到 Ruby 代码的 JSON 请求看起来像这样
api_response = {
headers: ["uniq_id", "email", "description"]
rows: [
[2345, 'foo@bar.car', 'first item'],
[9876, 'car@bar.foo', 'second item']
]
}
所以在我的脚本中,我想收集所有的 uniq id:
JSON.parse(api_response)
.fetch('rows')
.collect { |application_row| application_row.at(0) }
最好有一些能力来评论at(0)
正在获取的内容。就像sawa在他的评论中建议的那样,如果%c{}
存在的话,我可以做这样的事情:
JSON.parse(api_response)
.fetch('rows')
.collect { |application_row| %c{uniq_id}; application_row.at(0) }
......但后来我意识到我只是在愚蠢。自我代码应该自我解释我的意图
uniq_ids = JSON.parse(api_response)
.fetch('rows')
.collect { |application_row| application_row.at(0) }
在某些情况下,这不是一个选项,所以也许这可以解决问题:
JSON.parse(api_response)
.fetch('rows')
.collect { |application_row| uniq_id = application_row.at(0) }
...是的,这将导致使用未使用的局部变量,但是在这种情况下,这是可以的,因为代码的可读性将有利于不会过多地影响性能。
在 Pauls 的情况下,他只想从数组中删除一个元素。我猜他可能想要它用于调试目的,但一般的想法是 Ruby 强制你编写尽可能干净的代码并删除任何不会在生产中使用的东西。
解决方案可能是
my_array = ['first']
# my_array += ['second']
my_array += ['third', 'fourth']
这丑吗?嗯,是的,一般的想法是你应该在提交之前重新考虑它,强制你在投入生产之前删除丑陋的代码并删除不必要的东西。
更新 2019 05
我现在看到这个答案是 -1,它是 2014 年发布的。现在是 2019 年,我仍然有同样的看法 :) 如果你写了评论,你就没有编写清楚显示意图的代码 :)
肯定有需要评论的情况。但开发者的正确反应应该是:“天哪,有评论!我需要注意!”
我目前在该领域拥有 12 年的专业经验。并且在项目中一遍又一遍地看到这一点:如果代码中到处都是注释,开发人员将不再将注释视为有价值的信息,而只是不阅读它们。
但原则上,没有一个“让我们在这里发表评论”的单一用例无法通过良好的代码/架构设计来解决:)
引用Martin Fowler的话:
任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写人类可以理解的代码。