Learning / proper use of cond (and other Elixir style)

Questions / Help
, ,
1

Hey all dear Elixir fans and pros,

I try to learn with wiritng the most-elixirish functional code, sometime with the help of you.

I am just writing a parsing module, which extracts some info from recieved JSON (different shapes), and come up with this functions:

def get_markets do
    for {market, url} <- get_markets_urls() do # get_markets_urls just query my db for market name and it's url (about 5-10 records max.)
      case get(url) do
        {:ok, val} -> parse_markets(val.body, market)
        {:error, reason} -> IO.puts "Error: #{reason}"
      end
    end
  end

  defp parse_markets(response, market) do
    IO.puts "Parsing markets"
    cond do
      market == "Market1" ->
        IO.puts Enum.map(response, &(Map.get(&1, "asset")))
      market == "Market2" ->
        Enum.map(Map.get(response, "data"), &(marketClient(&1, market)))
      market == "Market3" ->
        IO.puts Enum.map(response, &(&1))
      true -> "Other"
    end
  end

As you can see, for every market I need to extract different info (because of different response shape).
Please, is this a good way to write it? Coud it be written by better, more functional way?

Thanks for the hints!

R.

2

Maybe You can improve with multiple functions… like this

defp parse_markets(response, "Market1"), do: #whatever
defp parse_markets(response, "Market2"), do: #whatever
defp parse_markets(response, "Market3"), do: #whatever
defp parse_markets(response, _), do: #whatever
4 Likes
3

As all your branches do compare for equality of market against a string literal a case were much more idiomatic.

Also I’m not quite sure why in the parse_markets/2 you are returning :ok (an atom) most of the time but "Other" (a string) on unknown markets.

1 Like
4

Also while there is nothing wrong with comprehensions it seems that your are holding on too tightly to iteration.

If you are going through the list for side effects I’d expect to see Enum.each/2 instead or if you wanted conditional transformation I’d expect some piped combination of Enum.filter/2 and Enum.map/2 (though comprehensions can have filters as well).

At the very least I’d make the comprehension look less like a loop, e.g.

def get_markets, 
  do: for {name, url} <- get_market_urls()
          do: get_market_data(name, url)

vs

def get_markets,
  do: Enum.map(get_market_urls(), fn {name,url} -> get_market_data(name,url) end)

or

def get_market_data({name,url}) do: 
  ...
end

def get_markets,
  do: Enum.map(get_market_urls(), &get_market_data/1)

(In general I’d dial back on the use of inline anonymous functions that is so common in JavaScript)

2 Likes
5

A “Clean Coder” advice: I would prefer the pattern-match solution by @kokolegorille for one reason: You can add new “Markets” without changing the existing code but by just adding a new function-header for “Market4”.

1 Like