Is there an good convention for renaming shadowed variables in 0.19?

[wbrian]

Elm 0.19 disallows shadowed variables, so I was wondering if there was a good (existing?) convention for renaming such variables. Obviously this may be context dependent in some scenarios, but I think a lot of people intentionally shadow variables when they want to use some transformed value throughout the rest of the function.

[nqthqn]

Maybe something like this?

case num of
    Just num_ ->

[evancz]

The most common case I saw was like this:

canVote : Maybe Int -> Bool
canVote maybeAge =
  case maybeAge of
    Just age ->
      age > 18
    Nothing ->
      False

So my first recommendation is to be more explicit in your naming.

If you find it hard to think of unique names, my second recommendation is to break out helper functions. Having smaller top-level functions can often make things clearer (and easier to test) and can give more leeway in naming things.

If you think that will not work for you, show specific code. We can provide specific suggestions.

Aside: I very highly recommend against approaches that lead to x, x1, x2 all over the place. It can be hard to pick better names or find smaller functions, but just do it.

[andys8]

What is the reason for recommending top level helpers. Is there a performance overheaded with helpers defined with let .. in ..? Just curious

[evancz]

Nah, that kind of thing doesn’t matter. I just found that having top-level functions worked really well for me in the past 9 years using languages like Elm. I usually arrange things in sections like this:

-- TOPOLOGICAL SORT

topologicalSort : Dict String (List String) ->  List String
topologicalSort graph =
  ... topologicalSortHelp ...

topologicalSortHelp : String -> Dict String (List String) -> List String
topologicalSortHelp key graph =
  ... whatever ...

whatever : This -> That -> Whatever
whatever this that =
  ...


-- SOMETHING ELSE

somethingElse : String -> Whatever
somethingElse blah =
  ...

I use the big -- COMMENTS to group things visually for quickly scanning through. I wrote about this style a bit in the revised guide actually!

I have personally found that this is when my code is easiest to understand and edit, especially when there were long gaps since I last saw it. The important part is that all necessary variables are clearly labelled, whereas when using let blocks, there can be values that just came from somewhere. So it may be annoying to “have more arguments” but to me that is the whole point. Clearly labelled with a type annotation!

Note: If it turned out that code in let was faster if it was taken out, that’s the kind of thing a compiler can do really easily. I would really discourage thinking about perf tradeoffs like that when writing normal Elm code. The new optimization section of the guide also gets into how that is a dead end in most cases anyway!