vb6 one class = one file

[mp]

now in c# one file, eg "Class1.cs" can have multiple namespaces
and each namespace can have multiple classes.

How do the experts use this?
What is the advantage/disadvantage of multiple namespaces per file and
multiple classes per namesp.
compared to having one class = one file?

thanks
mark'

 

[mp]

In general, you should try to stick with one type per file.

However, as with all rules, there are exceptions. It seems to me that
when the types are small and closely related, it may make more sense to
keep them in the same file. Likewise, nested types most often are best
included in the same main .cs file with their outer type.

I would definitely try much harder to avoid multiple namespaces in a file.
By definition, types not in the same namespace are _not_ closely related
and it seems to me a lot less likely that it could be successfully argued
that they belong together. Unlike for types generally, I can't think of a
good example of a situation where types from different namespaces belong
in the same file.

Pete

Thanks Pete,
I was actually surprised I could put mulitple namespaces in a file, but as
I'm doing a lot of copy/paste from various forums to learn c# (mostly on
acad forum) I have one project that is a bunch of samples i keep pasting
into the same file just to keep my c# acad learning stuff
together...somewhat accidentally seeing that I had diff names in same file
and many classes in same file.
Thanks for clarifying that's not how it "should" be done.
Mark

 

[J.B. Moreno]

now in c# one file, eg "Class1.cs" can have multiple namespaces
and each namespace can have multiple classes.

How do the experts use this?

The same way they use splitting a class across multiple files. As
needed.

What is the advantage/disadvantage of multiple namespaces per file and
multiple classes per namesp.
compared to having one class = one file?

It's all about the programmers mental model of the project, and how he
can best remember how to find what he needs to find. If it confuses
you, then don't use it, if it makes things more clear for you then use
it. Once the program has been compiled, what files your namespaces and
classes were in is totally irrelevant.

 

[mp]

The same way they use splitting a class across multiple files. As
needed.


It's all about the programmers mental model of the project, and how he
can best remember how to find what he needs to find. If it confuses
you, then don't use it, if it makes things more clear for you then use
it. Once the program has been compiled, what files your namespaces and
classes were in is totally irrelevant.

Thanks for the response.
makes sense

 

[Arne Vajhøj]

now in c# one file, eg "Class1.cs" can have multiple namespaces
and each namespace can have multiple classes.

How do the experts use this?
What is the advantage/disadvantage of multiple namespaces per file and
multiple classes per namesp.
compared to having one class = one file?

Multiple namespaces per file is not a good idea
in my opinion - it can be confusing to find things and
it somehow indicates that either the namespaces are too
small or the files are too big.

Multiple classes per namespace is a must. You can't
do proper OO design without it.

Multiple classes per file is in my opinion a good practice,
because it is easier to read N small classes in a single
file than N small classes in N files. Obviously N should not be
to big. Maybe max. 10.

Multiple files per namespace is a good idea when the files
becomes too big. When the files become bigger than 600-800 lines
then split them. In a way that keep related files together
under a name that is easy to guess for every class.

So:

namespace--1:1..*--file--1:1..*--class

Arne

 

[mp]

snip


So:

namespace--1:1..*--file--1:1..*--class

Arne

Thanks for weighing in...
mark

 

[Jeff Johnson]

Thanks for weighing in...

And here's my two cents with an example. Suppose you create a class that
raises an event and you need a custom EventArgs object to hold data specific
to that event. If this class is the only one that will use that particular
EventArgs class, then I wouldn't dream of defining the EventArgs class
anywhere but the same file where I am raising that event. But of course,
that's my personal style.

As a basic rule of thumb, I think .cs classes should hold one "main" class
and also any supporting classes/structs, if any, whose existence revolves
around that main class. Two "main" classes in a .cs file is a no-no to me.
And now an exception to the rule I just stated which I could tolerate:
Thinking about the EventArgs example earlier, I could stand having a single
..cs file which defines multiple EventArgs-derived classes, just like I can
stand a single .cs file defining multiple enums. It really is a case-by-case
thing....

 

[mp]

And here's my two cents with an example. Suppose you create a class that
raises an event and you need a custom EventArgs object to hold data
specific to that event. If this class is the only one that will use that
particular EventArgs class, then I wouldn't dream of defining the
EventArgs class anywhere but the same file where I am raising that event.
But of course, that's my personal style.

As a basic rule of thumb, I think .cs classes should hold one "main" class
and also any supporting classes/structs, if any, whose existence revolves
around that main class. Two "main" classes in a .cs file is a no-no to me.
And now an exception to the rule I just stated which I could tolerate:
Thinking about the EventArgs example earlier, I could stand having a
single .cs file which defines multiple EventArgs-derived classes, just
like I can stand a single .cs file defining multiple enums. It really is a
case-by-case thing....

Thanks Jeff,
mark