classes best practices

classes best practices

• kevin D. white

  Yes, it is perfectly normal to have lots of source files!
  
  I try to sub-categorise my classes using namespaces. And then I *always* make a new folder for each namespace and put source files for classes in that namespace into the corresponding folder (using nested folders for nested namespaces).
  
  In fact, if you use the IDE to create a new class in a subfolder in a project, it will automatically put that class into a namespace with the same name as the subfolder.
  
  To demonstrate this:
  
  (1) Create a default Windows Application.
  (2) In Solution Explorer, right-click the project node (not the solution node) and select Add|New Folder... and call it "MyNamespace"
  (3) In Solution Explorer, right-click "MyNamespace" and select Add|Class... and call the class file MyClass.cs.
  (4) Open MyClass.cs and observe that it has put the class into a namespace called <application namespace>.MyNamespace
  
  That's how you're supposed to organise disk folders and namespaces to make things consistent and therefore easier to navigate.
  
  
  

• Aayush Puri

  Christian & John,
  
  Thank you both for your insights; I do appreciate it. One general question I have that has spawned off from your post Christian is that, by making a seperate source code file for every class in the program; depending on the size of the program, that could generate hundreds of class files. Is this normal and if that is the case would you recommend then just creating a folder tree in the solution explorer For example would I want to create a folder called "Classes" and then in there create a folder called "Form 1" and then have all my classes in form 1 in there and then create another folder called "Form 2" and then have all my classes in form 2 in there Would that be the best way to manage all those class files
  
  Thank you,
  ~zero
  
  
  

• saurabhsule82

  Best practice IMO is to build a file per class, and only break that if a class only exists to serve another class ( if they are tightly coupled ). In that instance, I'd create the helper class as a child of the main class, so you can't scope it outside of scoping the main class name.

  All classes in one file is a maintenance nightmare.

  
  
  

• pickedname

  In my opinion it does not really matter at all how you orginize your code files, just do whatever seems to be reasonable...

  It is even valid to split one class over multiple files (partial class) if it makes sense to organize your code that way, e.g. if parts of your classes are automatically generated by another program. An example for this are the Forms you add to the Forms Designer, there is typically a generated part, e.g. Form1.Designer.cs.

  When you use tools on your source files like the designer, then there might even be some requirements how the code files must look like, because designable components must be the first class in the code file.

  
  

• JamesWhitfield

  A large project I would probably break up into a number of logical dlls and a main app that uses them. In the IDE, I'd also break sections of the project into folders to make it easy to find stuff that relates to one part of the program.

  I don't see any reason why classes would be tied to a form. They would be tied to specific behaviour in your app.

  
  
  
• classes best practices