Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Qqwy opened this issue Jun 17, 2017 · 1 comment

Comments

@Qqwy
Copy link
Contributor

Qqwy commented Jun 17, 2017

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
Copy link
Owner

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants