Namespaces in C# vs imports in Java and Python

Question

In the Java and Python world, you look at a source file and know where all the imports come from (i.e. you know in which file the imported classes are defined). For example:

In Java:

import javafoo.Bar;

public class MyClass {
    private Bar myBar = new Bar();
}

You immediately see that the Bar-class is imported from javafoo. So, Bar is declared in /javafoo/Bar.java

In Python

import pythonbaz
from pythonfoo import Bar

my_bar = Bar()
my_other = pythonbaz.Other()

Here, it is clear that Bar comes from the pythonfoo package and Other is obviously from pythonbaz.

In C# (correct me if I'm wrong):

using foo
using baz
using anothernamespace
...

public class MyClass
{
    private Bar myBar = new Bar();
}

Two questions:
1) How do I know where the Bar-class is declared? Does it come from the namespace foo, or bar, or anothernamespace? (edit: without using Visual Studio)

2) In Java, the package names correspond to directory names (or, it is a very strong convention). Thus, when you see which package a class comes from, you know its directory in the file system.

In C#, there does not seem to be such a convention for namespaces, or am I missing something? So, how do I know which directory and file to look in (without Visual Studio)? (after figuring out which namespace the class came from).

Edit clarification: I am aware that Python and/or Java allow wildcard imports, but the 'culture' in those languages frowns upon them (at least in Python, in Java I'm not sure). Also, in Java IDEs usually help you create minimal imports (as Mchl. commented below)

Answer 1

1) Well, you can do the same thing in Java too:

import java.util.*;
import java.io.*;

...

InputStream x = ...;

Does InputStream come from java.util or java.io? Of course, you can choose not to use that feature.

Now, in theory I realise this means when you're looking with a text editor, you can't tell where the types come from in C#... but in practice, I don't find that to be a problem. How often are you actually looking at code and can't use Visual Studio?

2) You can use the same convention in .NET too, of course - and I do, although I don't have empty directories going up the chain... so if I'm creating a project with a default namespace of X.Y, then X.Y.Foo would be in Foo.cs, and X.Y.Z.Bar would be in Z\Bar.cs

That's also what Visual Studio will do by default - if you create a subfolder, it will create new classes using a namespace based on the project default and the folder structure.

Of course, you can also declare types in any old file - but mostly people will follow the normal convention of declaring a type with a corresponding filename. Before generics made delegate declarations rarer, I used to have a Delegates.cs file containing all the delegate declarations for a particular namespace (rather than having a bunch of single-declaration files) but these days that's less of an issue.

Answer 2

1) You're right. There is no "direct" way to know where your class comes from at first glance, but, as you said, you can jump to it in the IDE. But declaring the class this way is just the shortest way to do it. If you wanted, and assuming your Bar class comes from the Foo one, you could declare it

private foo.Bar myBar = new foo.Bar();

This way it would help knowing where your classes come from at first look.

2)When you add a reference to your class, the Add reference windows gives you the informations you are looking for. And if you want to know where they come from after you declared it, there is a window named "Solution Explorer" where you can find these informations, under the "References" tree node. You can set it to be always visible (which it is by default)