How to organize classes/methods in Visual Studio
-
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
-
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
you can try to chop it to small files and create a partial class
Life - Dreams = Job TheCardinal CTC-RDG
-
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
Yes, definitely a good idea to keep one class per file as good programming practice. Um... Tradition? No. We (those at my company) like to strictly adhere to this rule and leave the partial class definition to automatically generated code only. Actually using it is IMHO a bit unsavory to read but preferable to a single file mess. You can use the #region directive to collapse source code sections together for convenience. Hope that helps Scott P
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” -Edsger Dijkstra
-
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
ssclaire wrote:
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct?
It all depends. I have files with one class and files with several classes and one class spread across multiple files. The key for me is to organize files in a logical, clear way. Having too many files can be as distracting and confusing as having few files with too much code in each.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Yes, definitely a good idea to keep one class per file as good programming practice. Um... Tradition? No. We (those at my company) like to strictly adhere to this rule and leave the partial class definition to automatically generated code only. Actually using it is IMHO a bit unsavory to read but preferable to a single file mess. You can use the #region directive to collapse source code sections together for convenience. Hope that helps Scott P
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” -Edsger Dijkstra
Partial classes are great for segregating related functionality into discrete files. For instance, I only put generated code into the main form file, and anything added manually into a separate file(s). For instane, all code related to a
BackgroundWorkerobject would go into a separate file."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
Don't worry about the length until the file gets to around 1000 lines of code. After that, you could try to find logical places to separate the code, and create partial classes.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
One class per source file is a good default convention, but a good programmer knows when to break the rules to improve clarity and simplicity. For example, it may be more maintainable to combine a few related classes that are only used together in the same file. Ask yourself: "What organizational structure would *I* prefer to work on when maintaining this system?"
-
I believe it is tradition/convention to organize source files in a project so each class is contained in one .cs source file. Correct? I am writing several static utility classes with about 10-20 methods each. And each will have about four (4) overloaded methods so the static class definition (and the .cs source file) is getting pretty lengthy. Should I keep to the one-class, one-source-file convention, or is there a better way to organize my project in the Solution Explorer?
