Can't use EOF heredoc

[chrisokamoto]

In the docs it says:

This cop checks that your heredocs are using meaningful delimiters. By default it disallows END and EO*, and can be configured through blacklisting additional delimiters.

But in the AllowedAcronyms' table, it says that EOF is allowed, but in fact, it isn't. When I try to use EOF, it says:

Naming/HeredocDelimiterNaming: Use meaningful heredoc delimiters. EOF

But I am not sure if I misunderstood it.

$ rubocop -V
0.52.1 (using Parser 2.4.0.2, running on ruby 2.4.1 x86_64-linux)

[mikegee]

It looks like it is trying to disallow "END" and "EO[A-Z]" like the message says.

I found "EOF" in an AllowedAcronyms list, but I think that list applies only to Naming/FileName, not Naming/HeredocDelimiterNaming.

[mcfisch]

The rule doesn't allow anything starting with EO or containing END. The rule isn't specific enough, and therefore actually doesn't really allow ANY meaningful delimiters. Changing it to this fixes it:

  Blacklist:
    - ^END$
    - !ruby/regexp '/^EO[A-EG-Z]{1}$/'

[mcfisch]

This would block all 3-char delimiters starting with EO as well as END, but still allow EOF. Will create PR for that.

[mcfisch]

Created #5712 to fix this. Tests passed, also works fine in my local ~/.rubocop.yml.

[Drenmi]

EOF was intentionally disallowed as a non-meaningful delimiter of this cop. The acronym list is for an unrelated cop. 🙂

If you want to use EOF in your project, the right way is to use the local configuration option. 😉

[mcfisch]

Ok, so it isn't related to the acronyms list, they just reside next to each other because they belong to the same category. Ok, I'll change the code accordingly.

However, the current implementation doesn't allow to have any delimiter starting or even containing EO[A-Z] or END, and I can't imagine this is on purpose, is it?

[Drenmi]

The rationale is it's an "empty" delimiter, which doesn't help provide context for what the contents of the string is. Compare:

foo = <<-EOF
  ...
EOF

to:

foo = <<-SQL
  ...
SQL

or:

foo = <<-ERROR
  ...
ERROR

In both the latter cases, you get an idea of what this string is, even without looking at the content or the variable name. In the case of SQL, most editors will also apply code highlighting to the string content.

[mcfisch]

The problem with the current definition is, that it even faults something like this just because it contains the banned pattern:

foo = <<-ENDPOVERTY
  ...
ENDPOVERTY

as well as

foo = <<-ISLEOFMAN
  ...
ISLEOFMAN

My change would limit it to just ban a solely used END or any other 3-char delimiter starting with EO.

[mcfisch]

I've changed the pattern to include EOF as well.

[Drenmi]

The problem with the current definition is, that it even faults something like this just because it contains the banned pattern.

Oh. Yes. This is definitely not intended. Good catch! 🙂

[mcfisch]

Thx for the merge, couldn't get back to it earlier.