Should Phoenix follow Elixir naming standards by default?

when using phoenix generators it creates MyAppWeb.ResourceController and put it inside /lib/my_app_web/controllers/resource_controller.ex file. I was thinking if it wouldn’t be better if it followed the elixir standards and have a MyAppWeb.Controllers.Resource in a /lib/my_app_web/controllers/resource.ex file.

I understand that this is done that way so phoenix can abstract the default view from the controller module name, but it could be an option passed to MyAppWeb when using it. Something like use MyAppWeb, controller: [default_view: ViewModule].


Well, people use alias a lot and having e.g. Users is going to be confusing, especially having in mind that Phoenix encourages you to have context modules with the model name in plural. So what would Users mean? The context or the controller?

Beyond the aliasing issue @dimitarvp mentions, the bigger concern IMO is the “tab problem”.

In short, having many files with similar / identical names can cause confusion when users have an editor that only displays the base name of the file as a label. In your example, is a tab labeled resource.ex the controller or the corresponding schema?

Rust had a similar (but bigger) situation a few years back; the “default” place to put code for a module foo was in foo/ - so if you had many crates open, ALL the tabs would be named :scream: The thread of discussion is long and tangled, but you can start from the final RFC that changed the approach so that would work.

Wouldn’t the easy solve there to use the :as option? Although as I type that I realize my approach in Elixir apps that have this problem is to just alias up to the namespace so I can reference X.Users and Y.Users in any module that needs to reference both.

Indeed but then why rename in the first place? You’d save writing something like 5-6 characters at best, at the cost of using unnecessary renaming in other form (namely the :as option).

Good point. It seems like the as option only really helps with the NS immediately above the mod isn’t enough to distinguish it but something higher up is. But I’ve never worked on a a system where that was true.

My rule of thumb for Elixir projects is: if your namespaces have 4 levels then it’s probably time to break apart your app.

As all such rules there are exceptions, obviously, but us the humans can only keep so much complexity in our heads.

BTW I never liked the “controller” moniker anyway. It’s IMO a misnomer and it would be more accurate as “HTTP inbound sink” (or something more brief than that; my English vocabulary isn’t great). The hell does it “control”?

If it were up to me I’d like have files like these:

  • lib/myapp_web/inbound/users_server.ex
  • lib/myapp/orders/cart.ex
  • lib/myapp_web/renderers/line_item_viewer.ex

Or some such.


@dimitarvp but why someone would reference a controller outside of a router or the actual controller test?

@al2o3cr isn’t that already a problem with the default elixir naming standard? why having two standards would solve that?

I think the main objective should be consistency. unfortunately, the web folder is an alien thing to the rest of the elixir code of a project.

1 Like

They very likely wouldn’t but aliasing things is a fact of life and IMO somebody is bound to get confused eventually. I wouldn’t risk it.

This is exactly the approach I am using in my projects. Example controller. I really do not like the default approach where the “regular” naming scheme is broken. Thanks to that approach it router is IMHO much cleaner:

scope "/", LangustaWeb.Controllers do
  pipe_through :browser

  get "/", Stories, :index
  get "/newest", Stories, :newest
  get "/newest/:name", Stories, :newest

  get "/s/:id/*rest", Stories, :show
  get "/t/:tags", Stories, :for_tags

  get "/u/:name", Account, :profile
  get "/login", Account, :login_form
  post "/login", Account, :login

  scope "/" do
    pipe_through :logged_in

    post "/s/:story_id/vote/:vote", Votes, :story

    get "/submit", Stories, :new
    post "/submit", Stories, :create

    delete "/logout", Account, :logout

See Mama, no Controller repeated over and over again.

However recently I am thinking about grouping the controller, view, and templates within single “domain-oriented” directory.


i’ve been doing that too. i’d love to see it as a standard in the framework, and I say that because generators usually direct people to a standard solution. i feel so weird on the projects that I’ve worked that are the necessity of custom plugs and people created and named plugs according to the “phoenix standard”.

personally I only use generators for migrations and everything else I create by hand so it doesn’t impact me that much. one other thing that I usually change is the folder names too:

├── web.ex
├── my_app.ex #application module
├── core
│   ├── repo.ex
│   ├── ...
├── web
│   ├── controllers
│   │    ├── ...
│   ├── templates
│   │    ├── ...
│   ├── views
│   │    ├── ...

However I keep the “regular” folder names as it makes vim-projectionist templates much simpler and working cross projects.

1 Like

@dimitarvp and @al2o3cr explained it beautifully. The alias/tab problem is untenable when you’d have a user.ex and User for the controller, the view, the struct, etc, and all the tests and what not. As a bit of history, I took the Controllers.User approach way back when I first started Phoenix and José is the one that recommended this change. So “standards” wise, this isn’t even a concern :slight_smile:


Sorry, but I’d say untenable is a strong word for this.
Most modern editors are configurable enough for the “tab” problem to be dealt with. Just looking for <editor> full path tab gives me:

for the “alias” problem a simple change from UserController to Controllers.User, UserView to Views.User would do the trick, and it’s just 2 characters added. I think it even makes it easier to alias in most use cases.