对于 rubocop 来说，如何处理一个关键的散列线太长了？答案

【问题标题】：What to do with a key hashed line is too long for rubocop?对于 rubocop 来说，如何处理一个关键的散列线太长了？
【发布时间】：2018-10-12 17:09:22
【问题描述】：

Rubocop 说这条线太长了

if paragraph.update(picture:
  contact_params[:menucontact_attributes][:paragraphs_attributes]['0'][:picture])

如何将contact_params[:menucontact_attributes][:paragraphs_attributes]['0'][:picture]) 拆分为多行？

【问题讨论】：

可能有menu_attrs = contact_params[:menucontact_attributes]，然后使用menu_attrs[:paragraphs_attributes]['0'][:picture]
或类似para_attrs = contact_params[:menucontact_attributes][:paragraphs_attributes]['0']
这里是否使用update! 和rescue 选项？这避免了 Rubocop 有一大堆规则的if 部分。我发现这种方法通常会导致代码更清晰，因为您的“异常”代码位于方法的末尾，并且默认行为没有缩进或特殊。
“无”是标题中问题的有效答案吗？

【解决方案1】：

我会选择（Ruby 2.3+）

contact_params.dig(
  :menucontact_attributes,
  :paragraphs_attributes,
  '0',
  :picture
)

请记住，与您的版本不同，如果这些属性中的任何一个不存在，它都不会崩溃。

【讨论】：

这是其中的一部分，但您还需要格式化 update 调用以使 Rubocop 停止运行。
正确，我坚持使用哈希部分，因为我不知道 OP 的 Rubocop 是如何准确配置的。
这里最大的问题是它在if 的上下文中，如果你制作这些多行的话，Rubocop 会变得有点短。将其分配给您可以测试的临时变量可能是诀窍。
推测，如果任何嵌套键不存在，编码器就会抛出异常。如果dig 通过nil，可以在被调用方法中引发异常，但这有点混乱。同样，当nil 是有效的返回值时，dig 的使用也会出现问题。
太完美了！只需按照 tadmand 的建议将 contact_params.dig(...) 分配给变量并将此变量传递给 update