"You should only have one top-level namespace and it should be the name of the application"

[Qqwy]

Recently, Eric Meadows-Jönsson noted to me that one of my Elixir libraries did not adhere to the following convention:

You should only have one top-level namespace and it should be the name of the application.

I had not heard this convention before, although I can certainly appreciate its worth (both greatly reducing the chance of libraries conflicting with each other because they happened to use the same names and making it more clear to the users of the library from what library a certain piece of code originates).

Needless to say, I have not adhered to this convention in the past in multiple places, resulting in libraries that I'll now release backwards-incompatible upgrades for.

In any case, I think that it might be good to add this rule to the style guide. (Unless, of course, there are people against it!)

[christopheradams]

This would be a welcome addition to the style guide. There a few rules to tease out:

• The top-level module namespace should be the same name as your application, that is, a CamelCase version of the snake_case application defined as the :app in your Mixfile. So MyApp for :my_app, but not for example My.App.
• You only need one top-level module namespace for your application, and all your modules should use it.

These are the relevant rules from publishing to Hex:

• If you are providing functionality on top of an existing package, consider using that package name as a prefix. For example, if you want to add authentication to Plug, consider calling your package plug_auth (or plug_somename) instead of auth (or somename).
• Avoid namespace conflicts with existing packages. Plug owns the Plug namespace, if you have an authentication package for Plug use the namespace PlugAuth instead of Plug.Auth.

Are there any other considerations?