How to avoid crazy naming conventions?

Is it common to name an assembly one name, name a folder inside of the assembly another and then start to carry those names into the classes inside of those folders? For example:

Project.Presenter
    Carriers
        CarriersFindPreferedCarriersPresenter.cs
        CarriersPreferencesPresenter.cs
        PreferredTargetLocationPresenter.cs

Project.Service.Fixture
    Carriers
        CarriersServiceFixture.cs

Or to carry this futher, even methods such as this:

List<PreferredTargetLocationPresenter.PreferredTargetLocation> 
newlyAddedPreferredLocations = new
List<PreferredTargetLocationPresenter.PreferredTargetLocation>();

newlyAddedPreferredLocations.add(destinationLocation.PreferredCity);        

To me this seems to grow more and more confusing as you work on a project longer and start to add additional assemblies and metho开发者_JAVA百科ds. Is there a better way to work with this?

Any feedback would be welcomed.

The Pragmatic Programmers popularized the DRY principle: Don't Repeat Yourself. This applies to naming too. Repeating the same scope names or prefixes again and again does not add any more information, just makes the names longer, less readable, easier to mistype and harder to search for. If you have 100 class names starting with PreferredLocation*, you are going to have a hard time finding the right one :-(

So I am fully against this. Class and method names are scoped by the enclosing path / project names (in java that would be package, in C# I don't know what the proper term is), so if you need all info about the whereabouts of a class/method, it's enough to look at the fully qualified name of it. However, in regular code one should not be forced to use the fully qualified name everywhere. The only exception is of name clashes, but I believe that should be treated as an exception rather than the rule.

Moreover, in a well designed app, most of the methods / classes are not globally visible, only inside their respective package (where the programming language allows this - Java does, I am sure that C# too). This lessens the risk of name clashes and obviates the need for class name prefixes even further.

Ask a hundred different people this question, and you'll get a hundred different answers. I'm a fan of whatever method makes writing/maintaining the code the simplest, which is long descriptive names half the time, and short and sweet names the other half. As long as the code is intuitive and flexible, I can't see a problem with either way.

Sometimes you'll have to use longer names, but you generally want to keep names as short as possible. The key is to have descriptive names, that give enough detail and no more.

Is PreferredTargetLocationPresenter.PreferredTargetLocation a subtype of the PreferredTargetLocationPresenter type? In other words, are you nesting classes?

If so, you might be better off breaking out PreferredTargetLocation into its own class. This allows you to write:

List<PreferredTargetLocation>

instead of

List<PreferredTargetLocationPresenter.PreferredTargetLocation>

If you are working in C# 3.0, you can shorten the declaration further by using var:

var locations = new List<PreferredTargetLocation>();