Welcome back to this final part of our four-part series on metaprogramming in Elixir.

Previously, we explored the various applications of macros.

In this part, we'll delve into common pitfalls that you might encounter when metaprogramming in Elixir.

Common Perils of Macros

According to the official documentation:

Macros should only be used as a last resort. Remember that explicit is better than implicit. Clear code is better than concise code.

While it may be tempting to use metaprogramming for everything, it may not always be the best option.

The Applications of Macros part of this series outlines the majority of use cases of macros.

However, you should only use macros with great caution.

We'll be looking at these three common pitfalls to avoid when using macros:

1. Injecting unnecessary functions
2. Over-injecting behavior
3. Replacing regular functions

Let's kick off by looking at what happens if you inject unnecessary functions into modules with macros.

Note: These points are inspired by Metaprogramming Elixir.

1. Injecting Unnecessary Functions with Macros

While macros can be used to inject functions into a caller, there are times where this is unnecessary.

Let's look at an example:

1defmodule CalculatorTransformer do
2  defmacro __using__(_) do
3    quote do
4      def add(a, b), do: a + b
5      def subtract(a, b), do: a - b
6      def multiply(a, b), do: a * b
7      def divide(a, b), do: a / b
8    end
9  end
10end
11
12defmodule Hospital do
13  use CalculatorTransformer
14
15  def calculate_cost(suite, procedure) do
16    add(suite * 20, multiply(procedure, 5))
17  end
18end

We inject various calculator functions into Hospital to eliminate the need for a module identifier.

However, the use of add and multiply now seem like they appear from thin air.

The code loses its semantic meaning and becomes harder to understand for first-time readers.

To preserve the semantic meaning of the code, define CalculatorTransformer as a regular module. This module can be imported into Hospital to eliminate module identifiers:

1defmodule CalculatorTransformer do
2  def add(a, b), do: a + b
3  def subtract(a, b), do: a - b
4  def multiply(a, b), do: a * b
5  def divide(a, b), do: a / b
6end
7
8defmodule Hospital do
9  import CalculatorTransformer
10
11  def calculate_cost(suite, procedure) do
12    add(suite * 20, multiply(procedure, 5))
13  end
14end

As well as creating unnecessary functions, macros can also over-inject behavior into a module. Let's explore what this means.

2. Macros Over-injecting Behavior

As Elixir injects macros into the callsite, behavior can be over-injected.

Let's go back to the example of BaseWrapper:

What if we left the parsing logic for post? within the __using__ macro?

1defmacro __using__(opts) do
2  quote location: :keep, bind_quoted: [opts: opts] do
3    # ...
4
5    def post?(url, body) do
6      case post(url, body) do
7        {:ok, %HTTPoison.Response{status_code: code, body: body}} when code in 200..299 ->
8          {:ok, body}
9
10        {:ok, %HTTPoison.Response{body: body}} ->
11          IO.inspect(body)
12          error = body |> Map.get("error", body |> Map.get("errors", ""))
13          {:error, error}
14
15        {:error, %HTTPoison.Error{reason: reason}} ->
16          IO.inspect("reason #{reason}")
17          {:error, reason}
18      end
19    end
20  end
21end

There are two issues with this approach:

1. By testing post?, you test the inheritor rather than BaseWrapper.

   As there are multiple inheritors of BaseWrapper and the entire behavior of post? is injected into the inheritor, we have to test every inheritor individually.

   This ensures that any inheritor-specific behavior does not modify the behavior of post?.

   Failure to do so can lead to lower test coverage.

2. Ambiguous error reporting.

   Any run-time errors raised by post? will be logged under the inheritor, not BaseWrapper.

Therefore, leaving the entire behavior in post? can create confusion.

The original implementation of BaseWrapper moves the bulk of the parsing behavior into the wrapper instead. This implementation is much neater, semantically more meaningful, and readable.

This minimizes the two issues mentioned above, as:

1. When you test the core behavior of post?, only BaseWrapper.parse_post is tested — not every single inheritor.

2. Any errors from parsing will be logged under BaseWrapper.

   Note: location: :keep works in a similar fashion.

While we've used wrappers in our example of over-injecting behavior, this can equally apply to regular macros.

A rule of thumb is to minimize the amount of behavior in a macro. Once the necessary information/computations that require a macro have been accessed/performed, you should move the remaining behavior out of the macro.

The final pitfall we'll examine is the use of macros when regular functions suffice.

3. Macros Used in Place of Regular Functions

As powerful as they are, you don't always need macros. In some cases, you can replace a macro's behavior with a regular function.

Let's say that behavior that does not require compile-time information (or a macro to perform computation) is placed in a macro, for example:

1defmodule Foo do
2  defmacro double(x) do
3    quote do
4      doubled = unquote(x) * 2
5      doubled
6    end
7  end
8end
9
10defmodule Baz do
11  require Foo
12
13  def execute do
14    Foo.double(3)
15  end
16end
17
18iex(1)> Baz.execute
196

Here, double could have easily been substituted for a regular function.

Its behavior does not require compile-time information nor a macro for computation. It will be injected into Baz and evaluated when execute is called, just like a regular function.

1defmodule Foo do
2  def double(x), do: x * 2
3end
4
5defmodule Baz do
6  def execute, do: Foo.double(3)
7end
8
9iex(1)> Baz.execute
106

As you can see, defining double as a macro does not pose any benefits over a regular function.

Metaprogramming in Elixir: Further Reading

We have finally come to the end of this investigation into metaprogramming in Elixir!

Remember: with great power comes great responsibility. Misusing metaprogramming can come back to bite you, so tread lightly.

While this series has aimed to explain metaprogramming and its intricacies concisely, it is by no means the "bible" on this topic.

There are many wonderful resources you can use to learn more about metaprogramming in Elixir! Here are just a few:

Written guides

• Understanding Elixir Macros - The Erlangelist*
• Official Elixir tutorial on metaprogramming
• Metaprogramming by Elixir School
• Metaprogramming in Elixir - Serokell

Books

• Metaprogramming Elixir*

Talks

• ElixirConf 2017 - Don't Write Macros But Do Learn How They Work by Jesse Anderson

( - highly recommended*)

Thanks for reading, and see you next time!

P.S. If you'd like to read Elixir Alchemy posts as soon as they get off the press, subscribe to our Elixir Alchemy newsletter and never miss a single post!

Our guest author Jia Hao Woo is a developer from the little red dot — Singapore! He loves to tinker with various technologies and has been using Elixir and Go for about a year. Follow his programming journey on his blog and [Twitter](https://twitter.com/woojiahao)._