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.
Maybe something like this?
case num of Just num_ ->
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
x2 all over the place. It can be hard to pick better names or find smaller functions, but just do it.
What is the reason for recommending top level helpers. Is there a performance overheaded with helpers defined with
let .. in ..? Just curious
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!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.