vb6 one class = one file

  • Thread starter Thread starter mp
  • Start date Start date
M

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'
 
Peter Duniho said:
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
Click to expand...
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
 
mp said:
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?
Click to expand...

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?
Click to expand...

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.
 
J.B. Moreno said:
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.
Click to expand...

Thanks for the response.
makes sense
 
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?
Click to expand...

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
 
Thanks for weighing in...:-)
Click to expand...

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....
 
Jeff Johnson said:
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....
Click to expand...
Thanks Jeff,
mark
 
Back
Top