2 Answers
2

As usual, that depends. It depends on the places where the unprefixed class names can be used. [Disclaimer: I'm a Java freak, but I think my experience will be applicable to C# as well.]

My rule of thumb is that symbols that are visible outside of their home namespace should have a unique name over all namespaces of the project.

If references to some Encoder will only show up in classes from the the same namespace, then, as a reader of the code, I'd expect the Encoder name to stand for the local one. In Java, I'd give the Encoder class a package-local visibility.

But if the Encoders are visible outside of their home namespace, I'd go for the long names.

E.g. Java has a negative example with the classes java.util.Date and java.sql.Date, which sometimes I had to use in the same method (bridging between core algorithm and database) - that forced me to use fully-qualified classnames at least for one of them :-(.

A unique name over all namespaces? Eeek! Not I - to each their own though, I suppose. (I thought namespaces were specifically to have to avoid doing that late 90s crap)
– jleachOct 17 '17 at 17:42

1

Of course, that's what namespaces are for. But what I try to avoid is e.g. having 5 different classes of the same name and usage all over the project, so I either have to prefix their usage with the namespace or I have to guess (look at the imports) which class it is.
– Ralf KleberhoffOct 17 '17 at 18:01

As someone who programs in both Java and C#, I can see the advantage of this, but it would get quite unmanageable after a while. The namespaces have to be distinct between one another and the classes within a given namespace must be distinct from one another. Anything else goes I think.
– NeilOct 18 '17 at 11:44

This ONLY applies to Java because Java either allows you to import a specific symbol (which then must have a locally unique name), or you must use the fully qualified name. So you get VorbisEncoder with import com.example.myapp.vorbis.VorbisEncoder or you have to spell out com.example.myapp.vorbis.Encoder each and every time. In languages with type aliases this does not apply.
– amonOct 20 '17 at 10:05

In this particular example, each codec has a different API due to the differences in the audio formats. There is a set of classes that implement a common interface, as you described, to provide a "higher-level" API for each codec.
– ABarneyOct 18 '17 at 20:51