Home/ Questions/Q 602713
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T16:51:07+00:00

Is it common to name an assembly one name, name a folder inside of

  • 0

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 methods. Is there a better way to work with this?

Any feedback would be welcomed.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0