Redundant folder name / module name?

Many projects, including Phoenix and Elixir itself, have a folder structure like this:


Is there a reason to place bar.ex outside of /bar? It feels both redundant and disorganized compared to a convention of, for example, /bar/main.ex.

The problem is especially apparent when you have a dozen different adapters or transports and your directory has 24 items (12 files + 12 directories) instead of just 12, or when you re-organize your code and forget to grab your bar.ex file.


I really like the idea of keeping all related files in a single directory. It really helps to navigate through big projects and it helps with moving stuff around (In my React projects I’m putting all component’s related files inside a directory, which is named as a component, and it worked great so far).

But If you would use /bar/main.ex your module should be named Foo.Bar.Main. What do you think about having /bar/bar.ex and keeping Foo.Bar as a name of the module?

My understanding/use of this layout is that the bar.ex file represents the public interface and what lays in bar/ are the implementation details behind it, and as such it is easy to see / find the public API of interest. When spelunking through other projects (i.e. libs from this is rather nice as one can go through those “public API” files and only dive deeper when needed.

Putting the mail file in bar/ itself eliminates that separation and loses the public API in a sea of “implementation detail” modules, and that creates a nice mental model when writing code as well.

So, at least for me, it works for both reading through other people’s projects and writing cleaner code. I agree it takes a moment to get used to and I’m sure it doesn’t work for everyone the same way it does for me … cheers! :slight_smile:


Elixir doesn’t care about your filenames as long as they end with .ex. So do whatever you and your team agree is best.

1 Like