Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One namespace on the whole project #272

Closed
trejjam opened this issue Dec 4, 2021 · 5 comments
Closed

One namespace on the whole project #272

trejjam opened this issue Dec 4, 2021 · 5 comments

Comments

@trejjam
Copy link
Contributor

trejjam commented Dec 4, 2021

Hi,
I did notice that the project define only one namespace (Fido2NetLib). It is a general practice, that namespaces match to folder structure. Do you mind, if I fix it?

@abergs
Copy link
Collaborator

abergs commented Dec 5, 2021

I'm not convinced of the value of this change. To me it feels like it would decrease discoverability of classes by introducing unnecessary structure.

I'm open to hear arguments.

@trejjam
Copy link
Contributor Author

trejjam commented Dec 5, 2021

I never thought to do otherwise. This library is the first I see with a single namespace all over projects. (I do not count Tests & Demo)

For me it brings clarity. When I want to use a type, I know where it comes from.

A simple example is hypothetical type Fido2.Lib.DependencyInjection.FidoExtensions. When you see FidoExtensions, you can expect a static class with static methods with the this keyword. But you do not know what it extends. When you see the namespace you know that it adds to the Fido.Lib extension methods related to DependencyInjection.

An example is Microsoft standard libraries which are divided by scopes.

I do understand that since you have got used to it...

@iamcarbon
Copy link
Sponsor Contributor

This sounds like it would introduce a lot of churn to the codebase and force a lot of downstream consumers to react to a change with no benefits. I'm unconvinced.

@trejjam
Copy link
Contributor Author

trejjam commented Dec 22, 2021

I recently noticed (felt) a tiny benefit. When you add a new public type to the codebase consumers of the library have 100% chance that they will got "hit" by it when they have the type of the same name in the current scope. With namespace-per-folder, you have better damage control.

Single namespace has a feeling of the "god" file - everything in a single file.

I understood your point of view. Feel free to close the issue if you want.

@kwaclaw
Copy link

kwaclaw commented Apr 5, 2023

In principle, having namespaces match the folder structure is not a bad idea, but there are also downsides.

Any restructuring of the folder structure breaks that guideline unless you also rename the namespaces.

In my work I decide on a case by case basis, often when I move code files into a subdirectory I adjust the namespaces only if the restructuring has meaning beyond simple file organization.

@abergs abergs closed this as completed Apr 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants