Discussion: namespace from directory structure

[alrz]

Keeping namespaces in sync with directory structure is usually a convention most of codebases follow. I think such feature would make that easier especially when public API contract is not an issue.

A simple syntax such as namespace; is needed to hint the compiler to choose a namespace based on directory structure.

Note: #2546 would only decrease nesting, but directory namespaces would make it entirely implicit.

[MgSam]

I'm not a fan of having code files have to be aware of the file system. It means moving a file around now becomes a breaking change. I write a lot of TypeScript as well as C#, and the fact that imports in TS/JS rely on file paths for correctness is one of the most painful and poorly designed things about the language, IMO.

[HaloFour]

I'm kind of with @MgSam on this one. Aside from CallerFilePathAttribute I don't think that the location of the source impacts compilation at all.

A feature like this would require a companion feature to establish the root path of the project, as not everyone would want the namespaces hanging off of the root project directory.

[franchyd]

That being said this could easily be a plugin/setting on an IDE rather than a language feature

[DavidArno]

I'm torn on this one.

I like the fact that R# warns/errors if the namespace doesn't match the file path (VS may do this natively now days; I've not checked). So I like the idea of not even having to specify the namespace, but to have it inferred by the file's location.

But I think @MgSam also raises some valid points against the idea.

So I've upvoted both the proposal and his counter argument. 😄

[MV10]

@HaloFour what, you don't look forward to using libraries like this? 🤣

namespace Users.JohnDoe.Source.Repos.Foo.Bar

[qrli]

Wow, my home folder name is not English and contains space 🤣

[ronnygunawan]

Creating a new .cs file already generates namespace based on directory structure. What you need is an analyzer with code fix to apply Refactor namespace to match directory structure fix to all files.

[MV10]

@ronnygunawan

Creating a new .cs file already generates namespace based on directory structure.

The request is to do this without explicitly specifying the namespace in the code file at all. The namespace would be derived from the file location only at compile time.

Bugs galore...

[HaloFour]

@ronnygunawan

Creating a new .cs file already generates namespace based on directory structure. What you need is an analyzer with code fix to apply Refactor namespace to match directory structure fix to all files.

I like this idea. An analyzer can warn that the namespace doesn't match the directory structure given a configured source root, and can offer a fix to update the namespace to match the location of the file. This would work similarly to how many IDEs deal with the package names of Java files.

[jagalves]

Some comments are really going overboard with the source root configuration. There's already a <RootNameSpace> configuration in the .csproj and the root can be the project file itself. No need to overcomplicate things. I mean, the new project type already automatically picks up .cs files under its path, why not automatically assign namespaces as well?

In my opinion this is how it should be:

• namespace declaration (and scope) not set: use the project's default + relative path to .csproj as namespace
• namespace declaration present: as it is today, don't break existing code and allow customization

Example:

• Project: c:\users\jagalves\projects\Stuff\MyProject.csproj (RootNamespace "MyProject")
• File: c:\users\jagalves\projects\Stuff\Utils\DateUtils.cs

If the file DateUtils.cs doesn't have a namespace{ } declaration, its namespace shall be "MyProject.Utils".

Today most people just do this but keep the redundant namespace declaration in every file.

[miloush]

If the file DateUtils.cs doesn't have a namespace{ } declaration, its namespace shall be "MyProject.Utils".

This would be a breaking change for code that does not specify namespace currently, as the types go into the global namespace.

[jagalves]

Hmm, it's global. I can see now why the OP suggested "namespace;" to trigger the feature.

Still think my suggestion should be considered for the next time .csproj gets breaking changes. Whenever it may be. ;)

[johnathaningle]

I would love to see this. I'm not sure if it is possible, but it would be nice if the namespace could be an optional statement. If no namespace is provided, the compiler will determine the namespace based on directory structure. This would (hopefully) solve the issue of backwards compatibility.

[miloush]

@jingle1000 as just noted namespace is already an optional statement

[ssg]

This sounds practical at first but I find it more problematic than file-scoped directives, because:

• Directories would be both used for semantic (aka public facing) grouping and logical (aka internal) grouping at the same time. That means directory structures like Controllers/Models/Views in an ASP.NET Core project would need to be split into separate namespaces. That means we have to litter the source code with multiple using statements for even small, logical groups like these rather than a single line of namespace directive per file. It would become annoyingly verbose and people would be discouraged to layout the source directory to their liking. This is my greatest issue with this proposal that it lumps semantic and logical grouping into a single scheme.

• There are many hardcoded directories in .NET projects which don't imply a namespace like App_Code, App_Data, App_Resources etc. This would cause confusion, problems.

• It would become impossible to deduce if a project uses namespaces or the global namespace by viewing the source code. You have to browse through csproj file, evaluate if macros if needed, just to assess this. It's unnecessarily vague. "Did the author forget the namespace directive or are they using global namespace?". I know that global namespace use is practically nonexistent which brings me to my next point:

• What if they forget to add "use directories as namespaces" option? That means everything would be lumped up in the global space and this may not be easily detectable, creating global namespace pollution and dirty code.

Even Java, which assumed that a file corresponded to one class, never assumed that a namespace would correspond to a directory.

[michalczerwinski]

As an author of the duplicated item I would like to fill in some things:

• it's nice to be able to opt in within specific file
• it would be nice to be able to override namespace for folder in VS (F4 for folder, then property Custom Namespace, similar to existing "Custom Tool Namespace" for items)
• having _Imports.cs might be an additional added value for this feature
• I think this might be a better syntax (but might be a matter of taste)

namespace default;

And please mind that this feature is available currently for razor files and it's really convenient!

[hez2010]

C# code can be compiled without file using Roslyn API. What if there's no actual .cs file but only C# code text?

[mormegil-cz]

Well, what does the [CallerFilePath] attribute do in that case?

[Trayani]

I'd rather have an option to declare containing namespace without braces and indentation.

[ssg]

and you've got it with C# 10 :)

[Joe4evr]

@Trayani #137

[ChristopherHaws]

If this were possible, it would pair very nicely with dotnet/project-system#5372

In the csproj you could do something like:

// MyProject/MyProject.csproj
<ItemGroup>
  <Folder Include="Models" Namespace="MyProject" />
</ItemGroup>

and files in that directory could exclude the namespace declaration:

// MyProject/Models/FooBar.cs
using System;

public class FooBar
{
}

In this case, FooBar would be in the MyProject namespace.

[miloush]

@ChristopherHaws

That would be a breaking change as that is already a valid code, as mentioned above in this thread.

I like the idea that namespace would be a property of folder and the tooling would generate new classes in the namespace as specified in the property. If people need files to be moved across folders and change their namespaces accordingly, then this should be apparent from the code.

[rcdailey]

[333fred]

To be clear, you have to consciously enable the analyzers that track these details. They're not enabled by default, and we don't have them enabled in the Roslyn codebase.

Directory structure is irrelevant

This is how namespaces in C# work. Yes, you can choose to make directory structure mean something. But you by no means have to.

[Zodt]

It seems to me that the best option should be the following implementation - explicit and implicit(@alrz) namespaces.

For example, we have a class SomeEvent. It is located in the directory ../Src/Project/Events/SomeEvent.cs.

• In case the namespace is not important to us, you can omit it in the file ../SomeEvent.cs.
  Then the compiler will generate a namespace by the directory for that file.

namespace Project.Events // implicit namespace

• In case the namespace is important to us, especially if we use MassTransit, we just prescribe the namespace as it is now.

namespace Project.Messages // explicit namespace

[TahirAhmadov]

That means you are unable to add something to the global namespace. While generally adding types to the global namespace is undesirable, making it outright impossible is a bad idea.

[rcdailey]

I know when it comes to developing language features, it's hard to say "keep it simple" because, in my view, it's the very job of this tooling to hide the complications that make KISS possible for folks like me. Best I can do is share my opinion here and hopefully it contributes to the cause.

For my day-to-day coding, I tend to keep my namespaces and file structure identical. As far as my work experience goes, this just feels like the de facto industry standard. More importantly, tooling like Resharper is constantly pointing out namespaces that do not match my directory structure. So, I've built up a habit over the years of fixing these "issues".

Having to explicitly and redundantly specify namespaces is a hinderance because each time I move a file, I have to "refactor" the namespace, which affects the file itself as well as anywhere that uses it.

If I take a few steps back, I'm not even sure why this convention exists. I come from mainly a C++ background and in that domain, the best practice was to always give a name to namespaces that represents the logical grouping or package of the code. I rarely let directories directly influence the namespace for at least the reason above: When a source file moves, there's no reason for the code to "break".

Maybe it's counter-productive to focus on the language here and instead ask ourselves why tooling like Resharper is doing this and why the convention matters. I'm a bit torn on this, to be honest. However, the conventions I must follow are (most of the time) not something I can change. So I do think it would be helpful for the language to assist in this convention, if it's reasonable to do so. And I only suggest that because of how widely this convention seems to be used; I'm very doubtful this is a fringe issue.

[HaloFour]

I almost think it was inherited from Java, where the package name must match the directory structure as that is how the compiler finds sources and classes on the class path. But I agree, the two should be independent, and for as far as individuals want to maintain that grouping it should be a function of tooling to ensure that the namespace and directory names are kept in sync.

[pinkfloydx33]

For what it's worth, you can disable the resharper warnings by disabling the "namespace provider" property in the resharper property pane when clicking on folders in solution explorer. I'm not sure how you do it globally however. Unfortunately I discovered that years after getting used to enforcing the rules and dealing with the refactoring disaster of moving a file. I just can't shake it as the norm now.

[maxtoroq]

Another syntax suggestion:

implicit namespace;

[VWilcox2000]

That appeals to me because I almost NEVER want directory / namespace to vary. Currently visual studio has a nice feature to automatically change namespaces when you drag files around -- if it could show the namespace to side of that, it would work for almost every file. Not sure if the practice is allowed, but if the compiler would freshly update implicit namespace; to implicit namespace MyProgram.Weather.Forecasting; based on folder and then if I move it elsewhere even outside of visual studio, on compile the namespace updated to the new folder (or if that's a no-no a warning generated that namespace does not match), I'd probably use it. I would also probably leverage such an option as a project level option for all namespaces if it existed.

[MV10]

As someone who thinks directory-based namespaces are a terrible idea, that approach would be nice because undoing it would be as simple as deleting the implicit keyword. Globally. Forever. 😂

[VWilcox2000]

lol, I can see new setup form for Visual Studio:

[ ] Support directory-based namespaces [ ] Prevent mention of directory-based namespaces
[ ] Use tabs for formatting [ ] Prevent tabs making it anywhere near your code.

[hez2010]

I don't think this is a good idea: it makes source rely on filesystem and directory structure, which is not always present or reliable.

[Rekkonnect]

Here's my take: this is not terrible an idea exactly because it would be opt-in. Moving files around during an API change should not be a breaking change for many, and in most cases you want to be structuring your project minimizing the risk of eventually getting it adjusted. You may specify the namespace declaration implication only on files that are the least likely to be moved elsewhere, or not at all. Both VS and Rider already provide a refactoring that automatically changes the namespace, and also apply it on files whose namespaces are already matching the folder structure.

For me personally, I rarely move files around after having pushed a release. Having something like implicit namespace; would definitely be convenient for me.

Also, the IDEs could support hinting the resulting namespace for the current placement of the source file in the project.

[binki]

Since global usings are already a compiler switch, I’d prefer this to be a compiler switch instead of a new directive in each file. Otherwise, you’re leaving behind unnecessary boilerplate.

[spydacarnage]

Global usings aren't a compiler switch - are you thinking about implicit usings? In which case, activating the switch essentially just adds a source-generated file to your compilation - it doesn't change the meaning of existing code.

[binki]

the switch essentially just adds a source-generated file to your compilation - it doesn't change the meaning of existing code.

With the file-scoped namespace «identifier»; statement, this is all that would be needed.

[spydacarnage]

But you'd need to be adding that to each file, which isn't very user-friendly.

[binki]

Ah, I didn’t understand what you meant. I thought you were saying a file was implicitly prefixed to every single compilation unit. I researched how global usings and implicit usings work, so I understand your response now. Implicit usings are implemented using global usings and source files generated by the buildsystem itself.

But the very feature I want is for the IDE0130 analyzer’s output to be used automatically. The analyzer’s implementation and even the way that embedded resource names are generated by the compiler means that the way to determine a good namespace for a file based on its filename is already solved. It’d be nice if C# could be handled more like .resx files in this respect.

[Phyyl]

I would love to see this as an opt-in project setting (e.g. <DirectoryBasedNamespaces>enable</DirectoryBasedNamespaces>). For some projects with rigorous structure, this would prevent namespaces not matching the folder structure. If you don't like it, don't enable it! Like @ssg mentioned, we would need a convention or an other setting for controlling the generated name... Personally, pascal case should be by default (ignoring spaces).

[binki]

The compiler and language are both entirely agnostic of directory structure, or that the C# source is contained in files at all.

How do #line and caller information work then? And, even without that, the compiler is aware of distinct “compilation units” which are the same concept as files minus path information.

I believe that the namespace directive should always explicitly be there

I think namespace is redundant boilerplate which is just noise and should ideally not exist. The files belonging to a specific namespace should be implied in the same way that files belonging to a specific assembly are implied—namely, by being in the correct directory. This would allow elimination of redundant noise.

I understand that you’re suggesting that we should do away with actually organizing code into directories or use meaningful filenames and instead just use an editor which displays shows a tree based on namespaces. Well, that doesn’t exactly work because the filename itself is still significant (especially for compilation units which contain multiple types) and using multiple directories is necessary to prevent filenames from colliding.

[HaloFour]

How do #line and caller information work then?

The former works fine with a string of source. The latter does depend on file information fed by the compiler but it is also entirely optional.

I think namespace is redundant boilerplate which is just noise and should ideally not exist. The files belonging to a specific namespace should be implied in the same way that files belonging to a specific assembly are implied—namely, by being in the correct directory. This would allow elimination of redundant noise.

I don't care how other people want to organize their projects. I think putting the source files into directories by namespaces is the redundant bit, not the namespace. It's a convention borrowed unnecessarily from other languages where source does need to be resolved this way. But if that's what you want to do, that doesn't bother me. However, I think making the namespace implicit is detrimental. I believe you should be able to look at the source by itself, without knowledge of any file structure, and understand where that code fits into the project as a whole.

As for making this optional per project, I think that ripcord should only be pulled in the case of absolute emergencies (like NRTs) and I don't think this remotely rises to the level of justifying a dialect.

I mostly write Java code, where file name and directory structure absolutely do matter and are required to align with the package and class name, and this is something I very rarely think about because the IDE (in this case IntelliJ) will automatically ask me if I want to change the package and class name. And I like that it asks first, because sometimes I make mistakes.

[spydacarnage]

I think namespace is redundant boilerplate which is just noise and should ideally not exist.

It's a single line and helps organise code into meaningful bundles. I wouldn't consider that redundant...

For instance, if I'm writing a helper assembly, I sometimes like to organise my enums in one folder, extension method classes in another, etc, so they're easier to find. I wouldn't want my library to have three namespaces to use the base classes, enums, and extension methods at the same time - I want them all to have the same as the parent "folder".

[MV10]

I think namespace is redundant boilerplate which is just noise and should ideally not exist.

No offense, but if you work with anything even a little bit complex, the namespace is an essential organizational tool. These days I primarily debug massive codebases written by others (sometimes 10 or 15 years ago where the dev is long gone). We don't typically have the source (or useful things like PDBs, comments, or variable names) -- we work off DLLs extracted from memory dumps. Most of this would be nearly impossible to reasonably review without namespaces grouping large-scale concerns.

I personally think tying it to any file-system hierarchy is stupid. They're different things with different purposes. For example, in complex systems I make heavy use of subdirectories to group related files which are still part of the same logical namespace.

Consider an example of where it would just be a pointless hassle. In one of my projects, I decided to treat this simple custom interface as if it was part of the MS DI namespace. Should I have artificially dug three directories deep for a couple lines of code?

namespace Microsoft.Extensions.DependencyInjection;

internal interface IAsyncSingleton
{
    public Task InitializeAsync();
}

But as long as it can be disabled as my default, I couldn't care less. (But the ILSpy maintainers are going to hate you if they suddenly have to start screwing around with directory structures... and who knows how many decades it'll be before windbg !wmodule -saveto would get updated? 😂)

[Phyyl]

The idea isn't to remove the namespaces at all or affect existing codebases, just adding an optional feature (opt-in) to generate the namespace based on the folder structure like many languages are doing (e.g. Rust). I understand that from a compiler standpoint it might not make a lot of sense but from a developer standpoint, files and folder structure is how we organize large projects (I work in a large project with tens of thousands of source files). Tools like ILSpy would never see the difference since there is a namespace after all, it's just generated.

[iam3yal]

I really think that it's something that the IDE should handle and there's no need to have this coupling between the file system and namespaces even though that generally I like to have them in sync.

p.s. Next someone might suggest implicit types names based on files names. 😄