Correct usage of source files and folders with namespaces

[karnac]

Greetings:

I'm a bit confused about namespaces. I know how they work, what I don't know is what an experienced developer would expect to see if they were looking at my code. Suppose for example I have two classes "Bar" and "Bas", and they are in the namespace "Foo". Would you expect to see:

• A directory named "Foo" with the files "Bar.vb" and "Bas.vb" inside - both of which use the namespace "Foo"?
• A directory named "Foo" with one or more *.vb files where the name roughly describes the functionality? E.g. a folder named "IO" might contain a file called reading.vb with all reading IO inside - while writing.vb might contain all writing IO inside.
• A file named "Foo.vb" in the namespace "Foo" containing the classes "Bar" and "Bas" (that's not necessarily in any particular folder)?
• ?? (profit?)

Thanks for any insights. BTW, I searched Google for variations on the theme "vb.net namespaces files and folders", but mostly got IO information. Not organization information.

 

[JohnH]

I think keeping one class in one file makes it easier when you need have both open for edit at the same time. Sometimes that is perhaps not important for small related classes. There is also the benefit of seeing which classes exist before reading all source code, documentation may not easily exist at various levels of development. When reading source code you may see class names that are unknown and wonder where they are, finding them is easier with good structure, while IDEs "go to definition" functionality mostly makes this pointless. If you for example look at the generated data access classes in VS like aDataset.Designer.vb you see they contain all related classes in one file and also a mixture of namespaces, but that may be only related to practical implementation of how the IDE manages a "single object package" and not done from a organizational best practice perspective. I can't see anything official regarding this in class library design guidelines, though the VS template is labeled as a "class file" and not a "classes file". On the other side classes can be nested and you can't divide that into different files without doing a Partial, which could introduce a new element of confusion. Using folders to signify namespaces sounds like a good idea for larger structures. This type of organization is probably more rewarding the larger things get, or when sharing code with others. Just some thoughts.

 

[karnac]

That makes sense. Thanks. For the moment I'm on my own learning, but soon our whole (small) team will be using vb.net, and I want to start off on the correct footing.

Using folders to signify namespaces sounds like a good idea for larger structures.

Using folders to designate packages and separate files for each class is the only way in Java (well more or less), so I found myself using "the Java way" without realizing it.

In the past I've bumped into Delphi code where it seemed like it was organized by monkeys. There were files named "joes.pas" and it would have all manner of stuff inside. I suspect that happened because nobody set a standard. Didn't want to start off doing that in vb.