Why are module names in Elixir UpperCamelCase, while the file names are snake_case?

Background

I have recently found an old article about Elixir, where the author explains some conventions about Elixir, and in specific, naming and structural conventions for Phoenix projects.

In this article the author mentions:

Module names in Elixir follow the UpperCamelCase convention. (…) and the file name has the same name as the module but uses snake_case as a convention. Why? I don’t know.

(emphasis added by me)

The author mentions the possibility of a technical reason for this. I am unaware of what technical reason could exist, and my belief is that this was mostly a style decision (needs confirmation).

Question

So the question here is the title:

Why are module names in Elixir UpperCamelCase, while the file names are snake_case?

The article is from 2022, so there is a good chance someone (maybe even the author) figured this one out. But I couldn’t find anything regarding this, and curiosity did get the best of me.

  • Why do you think this is the case?
  • What technical reasoning do you think could be behind this?

It’s just convention. This is how Ruby does it which of course inspired a lot of Elixir conventions. Also, Erlang modules names are conventionally snake case (and at least must start with a lowercase letter). There is no technical reason, but one thing to keep in mind is that file != module in Elixir, ie, you can have multiple modules in a single file. I often have some files that aren’t named after any of the contained modules, like errors.ex. For me (and this is just me), using camel case would suggest that the file is the module whereas snake case more correctly suggests there is no such correlation

4 Likes

Not all filesystems are case-sensitive, so trying to camel-case there will give you files with unwieldylongnameswithoutanypunctuation

I suspect that constraint in Elixir may have been more about “why are Ruby files named like this” and then migrated over, but I don’t have any evidence for that.

5 Likes

While it’s true much of Elixir’s syntax was inspired by Ruby, the root of it is almost certainly as @al2o3cr mentioned - not all file systems are case sensitive.

Then why is it such a prevalent convention in JavaScript? Also, BEAM files maintain the module name’s casing.

1 Like

No idea - maybe the creator’s of Ruby wanted to maintain compatibility with those systems?

For file systems that are not case-sensitive these would be the same:

TestsCase
TestScase

Haven’t watched it, but this might be worth a watch:

1 Like

Oh ya, I get the case-sensitive thing, I’m just asking—semi-rhetorically—why JS does if it can cause such problems. When it comes to source file naming, I’ve never been a fan of anything other than all lower snake or kebab case. I have a personal preference for kebab, but since Elixir doesn’t support kebab identifiers, I’m happy with snake.

EDIT: Oops, I think you understood this :grimacing: :sweat_smile:

1 Like

@ulissesalmeida I hope this post gives you the valuable information you were looking for, all those years back when you were writing the article.

If you found out something else that we don’t know, feel free to let us know!
I hope this thread finds you well and puts that pesky question to an end !

1 Like

Well something that no one has mentioned to this point; module names are also atoms. Therefore they must start with an uppercase letter. Hence I think it makes some sense to use camel case on module names simply to ease comprehension.

Nitpick for clarity: module names are aliases which is why they must start with an uppcase letter. And to nitpick myself, of course you can use straight up atoms as well, ie defmodule :foo, do: (). But yes, always atoms.

3 Likes

Excellent point. Hairsplitting may be unwelcome in other arenas but in software development it’s essential! :slight_smile:

3 Likes

TIL I can do

defmodule :foo do
  # ....
end

And it should work. :smiley:

1 Like

This is technically what you are doing when you do defmodule Foo do. Foo is like an “auto alias” as it expands to :"Elixir.Foo" so you’re really doing:

iex(1)> defmodule :"Elixir.Foo", do: (def hi, do: "hi")
{:module, Foo,
 <<70, 79, 82, 49, 0, 0, 5, 68, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 164,
   0, 0, 0, 17, 10, 69, 108, 105, 120, 105, 114, 46, 70, 111, 111, 8, 95, 95,
   105, 110, 102, 111, 95, 95, 10, 97, 116, ...>>, {:hi, 0}}
iex(2)> Foo.hi()
"hi"

Even though it’s pretty simple, I still get confused and I find it much easier to make the distinction when talking about them. And sometimes the difference is meaningful when a macro expects an (unexpanded) alias, like Phoenix.Router.scope.

3 Likes

Hehe. I once tweeted some “evil” Elixir in which I did defmodule :false do. Alas, someone reported it as a bug and it got fixed :grin:

edit: actually, I don’t think I needed the colon, but … details

2 Likes

This has some Scooby Doo villain vibes to it :grin:


On another note, I realized that a fun example of where alias vs atom matters is the alias macro! (Or is it a special form? I’m too lazy to check). It can only infer a value if given an alias, ie alias Foo.Bar. If given an atom, the :as option is required! alias :foo, as: Foo. This is the very type of thing I’m talking about that is both quite logical while being a little bit dizzying :brain: :face_with_spiral_eyes:

1 Like