When to use a variable vs simple value returning function

Questions / Help
1

Why would we use

def table do
  [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]
end

Rather than

table = [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]

In this example

defmodule KV.Router do
  @doc """
  Dispatch the given `mod`, `fun`, `args` request
  to the appropriate node based on the `bucket`.
  """
  def route(bucket, mod, fun, args) do
    # Get the first byte of the binary
    first = :binary.first(bucket)

    # Try to find an entry in the table() or raise
    entry =
      Enum.find(table(), fn {enum, _node} ->
        first in enum
      end) || no_entry_error(bucket)

    # If the entry node is the current node
    if elem(entry, 1) == node() do
      apply(mod, fun, args)
    else
      {KV.RouterTasks, elem(entry, 1)}
      |> Task.Supervisor.async(KV.Router, :route, [bucket, mod, fun, args])
      |> Task.await()
    end
  end

  defp no_entry_error(bucket) do
    raise "could not find entry for #{inspect bucket} in table #{inspect table()}"
  end

  @doc """
  The routing table.
  """
  def table do
    # Replace computer-name with your local machine name
    [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]
  end
end

Taken from docs

1 Like
2

I use functions in these situations to allow myself the liberty to replace a hard-coded constant with a value fetched from a configuration provider – be it plain normal OS environment variables, various secret managers like those found in the Kubernetes ecosystem, AWS-specific secret key-value stores etc.

But, if you are very sure you won’t need to fetch the value from the outside world then you might be better off served by using a module attribute because that makes the code a bit more readable and explicit:

defmodule KV.Router do
  @routing_table [{?a..?m, :"foo@computer-name"}, {?n..?z, :"bar@computer-name"}]

  def route(bucket, mod, fun, args) do
    # ...
    @routing_table |> use_it_here()
    # ...
  end
end

Putting constant values inside your code is a bad idea no matter the programming language. More often than not, you’ll find yourself needing to modify it down the line and then you’ll have trouble finding where did you put it exactly (trust me, we forget where we put stuff all the time). In Elixir, using module attributes clearly expresses your intent as “this is a constant value that I will use one or more times in the code of the module it’s defined in”.

8 Likes
3

Awesome reply, thanks

Could you please elaborate on this? I come from jsland and in most codebases it appears the convention is to stick all variables at the top of the scope.

4

Well, look at your route function above. The table() call blends in perfectly with everything else. Now turn that into an inline variable. Imagine you work actively on something else for 3 months and then come back to this code with the requirement to make that table configurable. Would you immediately remember where you put the hard-coded variable?

Yeah, that’s a bit better, and closer to what I showed you. It’s a good compromise.

2 Likes
5

Wonderful, no yeah I get it. So in this particular case module attributes would be equivalent to what I was asking

6

Yes, correct.

1 Like
7

To clarify what I think you mean, inline inside the code with no name to them, such as c = 6.28318530718 * r.

As opposed to putting up top @PI 3.14159265359 (dunno offhand if Elixir provides this but anyway, it could be considered “putting a constant value inside your code”, as it’s in the module) and in the code, c = 2 * @PI * r, or better yet of course circumference = 2 * @PI * radius. That would be perfectly cromulent, in fact generally the recommended way to go.

Would that be a fair interpretation of what you’re trying to say?

2 Likes
8

There’s :math.pi() in erlang.

3 Likes
9

Yes, that’s what I am saying. Lack of description of what the inline value is supposed to be is a very common problem in most codebases I ever reviewed and participated in.

2 Likes
10

Ah, yup. “Magic Numbers”, some folks call it.

2 Likes
11

Something that noone has mentioned yet, is that module attributes are only available in the module they are defined in. So if I have

defmodule A do
  @pi 3.14159
end

And I have

defmodule B do
  def pi, do: 3.14159 
end

Then I can do this:

B.pi() # 3.14159

But I cannot get the constant value I’ve defined in A. Sometimes I’ll actually do something like

defmodule Example do
  @constant "..."
  def constant, do: @constant 
end

The reason for this is inside the module it’s defined in I’d use it as a module attribute to quickly tell myself that this is a constant value. And the public function tells me that this constant is used elsewhere in the code, not just this module.

2 Likes
12

It’s not mentioned because module attributes are usually used as module-scope (private) constants. :man_shrugging:

That’s what I do most of the time, for future-proofing. But it was rarely needed.

1 Like
13

From the docs, it actually looks like functions are preferred over module attributes for constants unless you need the constant for a function definition (e.g. to match an argument or for a guard)

1 Like