When is it best to start a new file in a VS project?

Does anyone have a real world rule set for when it is good to start a new project file?

Sometimes I find myself sticking a helper class in the same file with an existing class and other times not.  Once compiled it doesn't matter but file decisions do impact source control and review and other such things.

The micro side of my brain says every class should be in its own file for granularity's sake.  Of course that granularity adds man hours.  The macro side says be more pragmatic.  Where's the middle ground.

Files? Wha??? What do you think god created the code-behind file for? Cram it all in there! Your events, interfaces, abstract classes, enums, business objects, data access classes, you name it! It'll all be there for you when you need it most. You can also use another great tool, "Find" or <CTRL><F>, to help you find stuff burried in the ball of mud you've just created. It's so awesome I can't even begin to tell you! Plus writing code like that will make it oh so easy to port your app to Metro when the time comes because you'll have fewer files to copy/paste. Cause you know it's really all about the skillz transfer anyway right?

Dave, I'm just playing with ya... I will leave you with some valuable advice my boss gives me at times like these: "Use your best judgement".

Have a great day!

New file for each class (unless it's a nested class). Coupled with a logical folder structure, it makes it easy to find classes without having to use search features (which get slow with very large projects).

Additionally, every time you edit a file you risk introducing bugs to the code; I prefer to limit my screw-ups to a single class at a time.

Herbie

Does anyone have a real world rule set for when it is good to start a new project file? 

If the project was not written by yourself or yours truly.

Interesting.  One file per class.  I didn't expect that response.

@Maddus Mattus: Ha.  It took me a few reads to get it.   For a minute or two I thought you were suffering from altitude sickness.

What about internal (not intended for external implementors) interfaces?  Similar to blowdart's enums it seems logical to put the base implementation of the interface and the interface in a single file.

23 minutes ago, davewill wrote

Interesting.  One file per class.  I didn't expect that response.

@Maddus Mattus: Ha.  It took me a few reads to get it.   For a minute or two I thought you were suffering from altitude sickness.

What about internal (not intended for external implementors) interfaces?  Similar to blowdart's enums it seems logical to put the base implementation of the interface and the interface in a single file.

What do you mean by "base implementation" of an interface? "Base" implies a hierachy of the implementations like in a class hierarchy, but the point of an interface is to not be fettered by a hierarchy in the implementations.

++ @Herbie and @blowdart

1 class per file - generally. Break the rule when it makes sense In addition to the rationale already given, it eases team work - especially if your source control employs a "Lock model".

@Maddus LOL you kill me

I try to keep to one class per file, unless it's a helper class.

I also try to keep my files arranged in folders that match up with the namespaces.

52 minutes ago, davewill wrote

Interesting.  One file per class.  I didn't expect that response.

@Maddus Mattus: Ha.  It took me a few reads to get it.   For a minute or two I thought you were suffering from altitude sickness.

What about internal (not intended for external implementors) interfaces?  Similar to blowdart's enums it seems logical to put the base implementation of the interface and the interface in a single file.

Internal or external, it's all public to someone.  Interfaces belong in their own file.  Classes belong in their own file.  Private constants that are internal to a class are a potential exception, but if there is any reason why those constants would ever need to be used externally, make them part of a class (so you can qualify them with a namespace) and put them in their own file.

The idea (for me) is that it forces you to think about the information you include in the class and can sometimes help you know when to refactor.

Just put all your source code in one big file. That way you don't need Solution Explorer or tabs. And searching becomes a lot easier. You could even use SpectateSwampSearch for all kinds of search awesomeness.

@TommyCarlier: Oh yeah!  You could get it to display random bits of code!  Wow.

Herbie

1 day ago, DeathBy​VisualStudio wrote

Files? Wha??? What do you think god created the code-behind file for? Cram it all in there! Your events, interfaces, abstract classes, enums, business objects, data access classes, you name it! It'll all be there for you when you need it most. You can also use another great tool, "Find" or <CTRL><F>, to help you find stuff burried in the ball of mud you've just created. It's so awesome I can't even begin to tell you! Plus writing code like that will make it oh so easy to port your app to Metro when the time comes because you'll have fewer files to copy/paste. Cause you know it's really all about the skillz transfer anyway right?

Dave, I'm just playing with ya... I will leave you with some valuable advice my boss gives me at times like these: "Use your best judgement".

Have a great day!

wow for a minute there i think you were channeling "SpectateSwamp"    

2 hours ago, TommyCarlier wrote

Just put all your source code in one big file. That way you don't need Solution Explorer or tabs. And searching becomes a lot easier. You could even use SpectateSwampSearch for all kinds of search awesomeness.

Not just that, but your code will run faster too!

@BitFlipper: I also remove all the spaces in my code, that makes it really fly!

Herbie

@Dr Herbie: Don't forget to use all upper case so there are less bits to flip on. 

And use only 2 or 3 letter names for classes, structs, members, locals, namespaces, filenames and enums. This saves both memory and speeds up performance.

@DeathByVisualStudio: you have some serious issues.