Improve this code?

I thought I would make one of these “improve this code” posts even though this problem isn’t really at that interesting (but here we are). I don’t hate my solution but I feel like it could perhaps be a little more readable. I’m not sure. It’s not bad, but maybe it could be better? Maybe there is an existing way to do this? I am aware of breadcrumble_ex but it’s too explicit for my use-case. I’d also like a better name, though not putting that on you all.

So this function takes a URI path (eg. /path/to/some/place) and turns it into a list of tuples suitable for a presenter to blindly turn it into breadcrumbs. Here it is:

defmodule ExampleModule do
  @doc """
  Takes a path and return a list of tuples in the form of:

    [{"segment", "/path/to/segment"}]

  ## Example:

    iex> ExampleModule.segment_path("/path/to/segment")
    iex> [{"path", "/path"}, {"to", "/path/to"}, {"segement", "/path/to/segment"}]

  This is useful for making breadcrumbs.
  """
  def segment_path(path) when is_binary(path) do
    path
    |> String.split("/")
    |> Enum.reverse()
    |> do_segment_path([])
  end

  defp do_segment_path([""], acc), do: acc

  defp do_segment_path([segment | rest] = path, acc) do
    path =
      path
      |> Enum.reverse()
      |> Enum.join("/")

    acc = [{segment, path} | acc]

    do_segment_path(rest, acc)
  end
end

That’s it!

Not too exciting, I know. I mostly like this little problem since this is one of those cases where building a list from the end is actually what we want to do. Of course, this just means we reverse it at the beginning as opposed to the end, and then again each iteration to put each segment in its correct form. That’s the big thing I think I would find confusing about this coming back to it later with no context.

Code-golf answers are welcome, but I’m ultimately looking for readability improvements.

4 Likes

YMMV as to where this falls on the golf-vs-readability spectrum, but it’s shorter:

def segment_path(s) do
  s
  |> String.split("/", trim: true)
  |> Enum.scan({nil, ""}, fn el, {_, path} ->
    {el, "#{path}/#{el}"}
  end)
end

The tricky part here is that we only care about part of the “accumulator” for Enum.scan.

Alternatively, you could divide the work into clearer parts:

def segment_path(s) do
  s
  |> String.split("/", trim: true)
  |> Enum.scan([""], &[&1 | &2])
  |> Enum.map(&{hd(&1), Enum.join(Enum.reverse(&1), "/")})
end

The scan here builds a list of lists with (reversed) paths:

[["path"], ["to", "path"], ["segment", "to", "path"]]

Then the map converts those into the desired output shape.

4 Likes

Here’s another option!

  def segment_path(path) when is_binary(path) do
    segments = String.split(path, "/", trim: true)

    paths =
      Enum.reduce(segments, [], fn
        segment, [] -> ["/#{segment}"]
        segment, [head | _tail] = whole -> ["#{head}/#{segment}" | whole]
      end)

    Enum.zip(segments, Enum.reverse(paths))
  end
end

What makes this more readable IMHO:

  • Fewer LOC
  • Contained in one function which tells me a clear story
  • Building the paths as we move forward in a visually clear way with interpolation rather than list |> Enum.reverse() |> Enum.join()
  • Only reversing one list at the end
  • Using Enum.reduce/3 which is very familiar to most Elixir devs

You can of course pipe the reduce block into Enum.reverse() instead of inlining it in the zip call, if that’s your preference

As an added bonus this implementation benchmarks 20% faster on my machine than your original :smile:

5 Likes

Another way:

def segment_path(path) do
  path_levels =
    path
    |> String.split("/", trim: true)
    |> length()

  path
  |> breadcrumb()
  |> Stream.iterate(fn
    {segment, segment_path} ->
      parent_path = String.replace_trailing(segment_path, "/#{segment}", "")
      breadcrumb(parent_path)
  end)
  |> Enum.take(path_levels)
  |> Enum.reverse()
end

def breadcrumb(path) do
  segment = path
  |> String.split("/")
  |> List.last()

  {segment, path}
end

The solution with this code unfolds like this:

path = "/some/path/to/nowhere"

1. {"nowhere", "/some/path/to/nowhere"}
2. {"to", "/some/path/to"}
3. {"path", "/some/path"}
4. {"some", "/some"}

Then it’s reversed.

I won’t add reasoning on why (or whether) this is better, but just another implementation. :slightly_smiling_face:

3 Likes

Awesome, thank you all for your responses!

Enum.scan.3 is actually what I was looking for, but the name didn’t poke out to me. Looks like I need to just do another read-through of the entire Enum module as it’s been quite a while. Stream.iterate/2 is super interesting and was wholly unaware of it.

@msimonborg I like your points but interestingly or not, I always do my best to find an alternative whenever I find myself needing reduce. It’s not that I think it should never be used, and it certainly is sometimes, but I feel it hurts code “scannability”. Since reduce is the most generalized enumerator you can get, just reading its name alone tells an incredibly generalized story about what is about to happen. This forces me to read through a bit of the implementation, even if I don’t care about it, thus hurting scannability. So I always look for an alternative in Enum that is going that is more tailored to what I want to accomplish. Of course, in this instance, not only did I completely miss scan/3, I chose recursion which is definitely not more “scannable”. While I don’t avoid reduce at all costs, I was definitely trying to do so and took it a little too far this time.

That said, I would say that the scan/3 solution is my favourite here. While I somewhat agree that it is better to use functions that more people are familiar with, I feel like once you come across a function a couple of times and look it up it becomes pretty ingrained. Now that I know about scan, just seeing the name itself will give a lot of information about what’s about to happen, and I prefer optimizing for that.

Anyway, thanks again, all—Glad I asked!

2 Likes

Still a newb so looking for feedback on if this would work:

defmodule ExampleModule do
  @doc """
  Takes a path and returns a list of tuples in the form of:

    [{"segment", "/path/to/segment"}]

  ## Examples:

    iex> ExampleModule.segment_path("/path/to/segment")
    iex> [{"path", "/path"}, {"to", "/path/to"}, {"segment", "/path/to/segment"}]
  """
  @spec segment_path(binary()) :: [{String.t(), String.t()}]
  def segment_path(path) when is_binary(path) do
    path
    |> String.split("/", trim: true)
    |> Enum.scan({nil, ""}, fn
      el, {_, path} when is_binary(path) ->
        {el, "#{path}/#{el}"}
      _, _ ->
        :noop
    end)
    |> Enum.map(fn
      {seg, path} when is_binary(seg) and is_binary(path) ->
        {seg, path |> String.split("/") |> Enum.reverse() |> Enum.join("/")}
      _, _ ->
        :noop
    end)
    |> Enum.reject(&(&1 == :noop))
  end
end

+1 haha. Wonder what your final solution is as a certain lib I am building could use this as extension…

This was for one of my several abandon projects so it never grew. At one point I had my personal site in LiveView until I decide to switch over to Hugo. This is what I landed on but it didn’t have time to grow. It’s based off of @al2o3cr’s first suggestion suggested along with a component. I just build up segments are two-tuples with {segment, path}.

As this is old code I’m not going to look over it to see if I’m embarrassed by it or not as I might not post it :upside_down_face:


  # In a Utils module

  @doc """
  Taks a path and return a list of tuples in the form of:

    {"segment", "/path/to/segment"}

  ## Example:

    iex> segment_path("/path/to/segment")
    iex> [{"path", "/path"}, {"to", "/path/to"}, {"segement", "/path/to/segment"}]

  This is useful for making breadcrumbs.
  """
  def segment_path(path) when is_binary(path) do
    path
    |> String.split("/", trim: true)
    |> Enum.scan([""], &[&1 | &2])
    |> Enum.map(&{hd(&1), Enum.join(Enum.reverse(&1), "/")})
  end

  # In a components module

  def breadcrumbs(assigns) do
    admin_path = String.replace(assigns.current_path, ~r/\A\/admin/, "")
    breadcrumbs = segment_path(admin_path)
    breadcrumbs = [{"dashboard", ""} | breadcrumbs]

    last = List.last(breadcrumbs)

    assigns = assign(assigns, :breadcrumbs, breadcrumbs)

    ~H"""
    <div class="cursor-default">
      <%= for {name, path} <- @breadcrumbs do %>
        <span class="after:content-['/'] after:text-gray-500 last:after:content-['']">
          <%= if {name, path} == last do %>
            <%= String.capitalize(name) %>
          <% else %>
            <.redirect to={"/admin#{path}"}><%= String.capitalize(name) %></.redirect>
          <% end %>
        </span>
      <% end %>
    </div>
    """
  end

Ok, I did look it over. It’s a little more complex than it needs to be for a show-and-tell but the admin specific stuff is because I was only using them in the admin section. segment_path/1 is the main thing. This was pre-verified routes and one of the reasons I was excited about them.

EDITED: Man, I really didn’t re-read this thread before posting. Sorry for the repeated context.

Just my 2 cents if I was a reviewer:

I’d recommend keeping your original code to segment the path - the new code might be more efficient, but I’d care more about readability than efficiency in code that deals with a string and resulting list of maybe 5 items.

Rename the private functions to something like

defp named_segments...

Otherwise perfectly fine for what it needs to do.

1 Like

For utility functions like these that do one very simple tiny thing that will very likely never change (and I wish were just in a library), I prefer them to be terse. When they take up a lot of lines it psychologically makes me think they are doing something really important when skimming through code. That’s just me and my personal projects, though. If I wrote that as part of a team and someone wanted me to change it, I wouldn’t protest.

If I wrote this today (this was 9 months ago… I just got pinged on this relatively old thread) I would probably expand the shorthand anonymous functions.

The do_ for private functions that recurse is a very common Elixir idiom which is why I do it. I didn’t like it at first but I really like it now as it acts as general visual “glue” for all recursive functions.

do_ for recursive functions is something the core team has explicitly moved away from, on the base that it’s just lazy naming, and leads to move your core logic into a private function - which is like stuffing your mess into a closet, close the door and call the room “cleaned up” :slight_smile:

My opinion on this: if you can’t come up with a name for your recursive function other than do_public_fun, then your logic should probably live in the public function.

In complex cases for sure—I did a little parser thing once and didn’t use do_ at all, but I honestly don’t write a lot of recursive functions. I mostly do simple cases and (and I’m entering into mega bikeshed territory here) I hate when things have names for the sake of having names… if that makes sense? Like when I see _other -> true in a catch-all or the like. I name my _ vars 99% of the time but case like that I’m like, “Duh, I know it’s ‘other’!”

I dunno, I’m procrastinating on a project right now :sweat_smile:

1 Like

Hopefully this is at least par for the course :golf:. @Ninigi I’m interested in what you’d use instead of do_ here.

defmodule Example do
  def segment_path(path) do
    path |> String.split("/", trim: true) |> do_segment_path("")
  end

  defp do_segment_path([], _path), do: []

  defp do_segment_path([current | rest], path) do
    new_path = "#{path}/#{current}"
    [{current, new_path} | do_segment_path(rest, new_path)]
  end
end

Running:

iex(1)> Example.segment_path("path/to/segment")
[{"path", "/path"}, {"to", "/path/to"}, {"segment", "/path/to/segment"}]
3 Likes
import Enum

def bread(p), do: p |> String.split("/") |> split(-1) |> bread_()

defp bread_({[], _}), do: []
defp bread_({p, [s]}), do: [{s, join(p ++ [s], "/")}] ++ (p |> split(-1) |> bread_())
bread("/path/to/segment") #=>
 [{"segment", "/path/to/segment"}, {"to", "/path/to"}, {"path", "/path"}]

this is inefficient, but easy to follow and short. I opt for easy here because this will never be time critical.
“Fast-readability” is also a kind of fast code.

With a for comprehension:

iex(109)> sp = fn path ->
...(109)>   split = String.split(path, "/")
...(109)>   for el <- split do
...(109)>     path = Enum.take_while(split, & &1 != el) ++ [el]
...(109)>     {el, Enum.join(path, "/")}
...(109)>   end
...(109)> end
#Function<42.3316493/1 in :erl_eval.expr/6>
iex(110)> sp.("path/to/some/segment")
[
  {"path", "path"},
  {"to", "path/to"},
  {"some", "path/to/some"},
  {"segment", "path/to/some/segment"}
]
2 Likes

I loved how simple and straightforward this looks!

1 Like

lol, thanks for necroing this thread as made me realize I never marked a solution :sweat_smile:

Late to the party here, but I’d use the Path helpers:

  def segment_path(path) when is_binary(path) do
    do_segment_path(path)
    |> Enum.reverse()
  end

  defp do_segment_path("/"), do: []

  defp do_segment_path(path) do
    [ { Path.basename(path), path } | do_segment_path(Path.dirname(path)) ]
  end
3 Likes

I mean, ya, that one certainly works well :sweat_smile: