Added avoid repeating module name rule

[corroded]

This is for #102

[eksperimental]

For me this is somewhat misleading.
Why would you want to alias to a module within itself.
You should be using __MODULE__ instead

[eksperimental]

I would add a link to the beginning of the thread. not to the middle.

[corroded]

Sorry, pasted the wrong link lol. All good 👍

[eksperimental]

✂️

[eksperimental]

✂️

[eksperimental]

✂️

[corroded]

@eksperimental addressed your comments :) Let me know if it needs more work. For examples, I just copied it from the original issue - I am still not that adept in Elixir to provide a better example (this is my way of studying/learning it)

[eksperimental]

I would replace "name" with "fragment"

[eksperimental]

this is still not preferred. as you do not solve anything.

[corroded]

Can you please help me with a better example for this? I was just following the original thread and the issue so not sure what a good example would be. To be honest, I would never name something consecutively like the example so really couldn't think of a use case where that is even possible.

[eksperimental]

I don't think this is clearly explained.
The whole reason for not repeating fragments in the module name is because when they are aliased, it could be ambiguous to which module you are refereing to.

examples.

# not preferred
defmodule Todo.Todo do
  ...
end

defmodule AnotherModule do
  alias Todo.Todo
  # here it is ambigious to which one we refer when we call `Todo`
end

I think those would be more real life examples, as in the examples given the proper way to refer to module from within is using `__MODULE__` not matter what is called. the problem is when aliasing from another module. 

[DavidAntaramian]

I feel like this is not a solution. Overall, this is an example of a poor naming structure. This is solved by having a rational alias pattern, not by being tricky with alias calls. As Jose specifically says in the original forum post which elicited this change:

If the naming schema is confusing, I can't think of a better option besides changing the name. Why not call it Todo.List for the whole list and Todo.ListItem or similar for every element?

The solution, in my opinion, is to change the alias to something that won't cause confusion.

[corroded]

@DavidAntaramian @eksperimental how about this:

  # not preferred
  defmodule Todo.Todo do
    ...
  end

  defmodule AnotherModule do
    alias Todo.Todo
    # here it is ambigious to which one we refer when we call `Todo`
  end

  # preferred
  defmodule Todo.List do
    ...
    # Basically, you should consider a better name for your module
    # if you ever find yourself duplicating fragments.
  end

I think if you're duplicating your module names/fragments, it is already a code smell. I totally agree with both your sentiments (including Jose's) that you should just pick a better name than duplicating something. It is too ambiguous and confusing.

[christopheradams]

I think it can be simplified. I think it just needs two brief examples with no additional comments of the style that is not preferred (Todo.Todo) and preferred (Todo.Item or Todo.Note). The reasons are clearer naming structure and no chance of ambiguous or confusing aliases.

[christopheradams]

• Avoid repeating fragments in module names and namespaces. This improves overall readability and eliminates ambiguous aliases.

# not preferred
defmodule Todo.Todo do
  ...
end

# preferred
defmodule Todo.Item do
  ...
end

[corroded]

@christopheradams I've changed this to what you have said 👍 thanks!