Readability trade-off with fwarn-name-shadowing

Question

I recently turned on GHC's -Wall option, which includes -fwarn-name-shadowing. The rationale offered is:

This option causes a warning to be emitted whenever an inner-scope value has the same name as an outer-scope value, i.e. the inner value shadows the outer one. This can catch typographical errors that turn into hard-to-find bugs.

But in practice I haven't caught any bugs with it yet, but I have made the variable naming in my functions a lot more awkward to work around it. Abbreviated example:

-- General method for parsing a paragraph.
paragraph :: Parser Node
paragraph = undefined -- omitted for brevity

blockquote :: Parser Node
blockquote =   lookAhead (char '>')
           >>  Blockquote
           <$> paragraph' `sepBy1` blankLine
  where
    -- Avoid shadowing a `paragraph` method defined above.
    -- This one is more specialized and relevant only in
    -- this context.
    paragraph' = Paragraph <$> body

This seems a bit smelly to me, but I have other cases that are much worse — for example I have one function where I end up avoiding shadowing remainder and sections by using remainder' and sections', and then in a nested where clause I go straight to r and s to avoid further shadowing — and I'm wondering whether -fwarn-name-shadowing is on the balance net positive. I think there is some refactoring I can do to avoid some shadowing without incurring the indirection of these awkward names, but it's not always possible.

Am I better off allowing some shadowing, or should I instead be looking to refactor examples like this to make the smell go away? I suspect the latter, but I am not sure.

Answer 1

Fair enough , I just add a similar problem where finding two different name is difficult. I still think name shadowing us a code smell and trying to find different meaningful names must be considered first.