ruby-style | personal Ruby Style Guide along with tools you can use | Document Editor library

You are missing the difference between the scopes of variables.

The bang is always used to mark the "more surprising" (I don't particularly like the definition that uses "dangerous") of a pair of methods that do the same (or almost same) thing in a slightly different manner.

In both of your cases, there is no second, less surprising, method, so in both your cases, you don't need and should not use a bang.

There are plenty of examples of methods that, e.g., mutate the receiver and don't have a bang:

• Array
  • Array#append
  • Array#clear
  • Array#delete
  • Array#delete_at
  • Array#delete_if
  • Array#fill
  • Array#insert
  • Array#keep_if
  • Array#pop
  • Array#prepend
  • Array#push
  • Array#replace
  • Array#shift
  • Array#unshift
• Hash
  • Hash#clear
  • Hash#delete
  • Hash#delete_if
  • Hash#keep_if
  • Hash#replace
  • Hash#rehash
  • Hash#shift
  • Hash#store
  • Hash#update
• IO
  • Many methods in IO will in some way make changes to the I/O stream, such as advancing the file pointer (anything with read, write, print, or put in it, for example) or writing something to it (print, puts, anything with write in it).
• Module
  • Many methods in Module will in some way change the module; in fact, they would be pretty useless if they didn't! E.g. Module#alias_method, Module#define_method, Module#attr, Module#attr_reader, Module#attr_writer, Module#attr_accessor add methods to the module, and Module#prepend and Module#include modify the ancestry chain.
• Random
  • Methods that return random values will change the internal state of the pseudo-random number generator: Random#bytes and Random#rand.
• String
  • String#clear
  • String#concat
  • String#force_encoding
  • String#insert
  • String#prepend
  • String#replace
  • String#setbyte
• Object
  • Object#define_singleton_method
  • Object#extend
  • Object#freeze
  • Object#instance_variable_set
  • Object#remove_instance_variable
  • Object#taint
  • Object#trust
  • Object#untaint
  • Object#untrust

These are only some of the methods that I can think of off the top of my head that mutate their receiver. There are also other "dangerous" / "surprising" methods that are dangerous or surprising in a different way than mutating their receiver which don't have a bang: Module#private, Module#protected, and Module#public modify the way other things work which are evaluated in the same scope, e.g. method definitions. String#intern and String#to_sym mutate the global symbol table. Kernel#load, Kernel#require, and Kernel#require_relative mutate $LOADED_FEATURES. Many Regexp methods modify the thread-local global pseudo-variables $1, $2, $3, $4, $5, $6, $7, $8, and $9.

Obviously, the whole point of writer methods such as attribute writers (e.g. foo=) and indexing writers ([]=) is to mutate the receiver. There are also plenty of operator methods that mutate the receiver (e.g. Array#<<). However, in all of these cases, it doesn't make sense to add a bang to the name.

There is also one operator method whose name is the bang, namely BasicObject#!, but applying the rule about bang methods to this is obviously silly.

The! takeaway! is! that! bang! methods! should! only! be! used! for! marking! one! method! of! a! pair! if! you! use! bang! to! mark! every! potentially! unsafe! method! Ruby! would! get! very! annoying! to! read!

As a closing remark, I want to address a tiny part of your question (bold emphasis mine):

The names of potentially dangerous methods (i.e. methods that modify self or the arguments, exit! (doesn’t run the finalizers like exit does), etc) should end with an exclamation mark if there exists a safe version of that dangerous method.

Methods should never mutate their arguments. Period. That is so surprising and dangerous, no amount of exclamation marks are warning enough.

Your code works, but is actually bad code. Indeed it should be written as fileName, although a Rubyist would not name a variable like that in camel case.

However, it would be better to write shorter, like

I can't add more to Rubocop's error description, it's clear and comprehensive. Adding brackets to -1:

The rationale is omitted in the initial commit, of which this rule was part, indicating that there was no particular technical reason for it.

The fact that the corresponding cop is placed in the Style department, rather than Lint, serves as further proof that this is a matter of just that, style.

Method definitions have a very simple syntax. The def keyword is (optionally) followed by arguments, which must be followed by a terminator (newline or ;).

The possible variations are:

• single line method definitions,
• inline modifiers, e.g. private,
• default- and keyword arguments,
• splat- and block arguments.

All of these work fine both with and without parentheses. Furthermore, running a file with an unparenthesized method definition using the -w flag raises no warnings.

These factors together rule out the possibility that the parentheses are recommended to avoid ambiguity.