C#: Un-nested struct in same .cs file as related class?

Question

If I'm dealing with one class and one public struct (not nested), Should I create a separate .cs just for the struct? Or leave it un-nested in its .cs file of the class? (This is assuming the struct relates to the class, but isn't so exclusive to the class that it should be nested and declared private)

Edit: I removed my initial question about two classes because I found C# classes in separate files?

score 6 · Accepted Answer · answered Mar 18 '11 at 20:17

Note that the only person(s) that can accurately answer this question is you, and your team. If your team is happy to find several related types inside a single file, combined due to ... whatever... then what I, or whomever other person, says, should be just ... irrelevant.

In any case, I would turn the question upside down:

Is there any reason to place two separate types (related by names, functionality, or whatever, but separate nonetheless) in the same file

and I've yet to come up with a good reason.

There are extensions/addins to Visual Studio where you can type in the name, and quickly navigate to the file, and I can think of three, but there are undoubtedly others:

The first allows you to quickly navigate to a file by name. If you know the type, but have people putting multiple types into the same type, this will not be helpful, at all.

The second and third, lets you navigate to a type by name, but you shouldn't rely on people having those, or knowing how to use them.

To that end, I would advocate following these rules:

Project names should be identical to the root namespace of that project. I differ from this point myself where in some cases I name my projects "...Core", and I then remove "Core" from the namespace, but otherwise, leave the project name identical to the namespace
Use folders in the project to build namespace hierarchies
The name of a type should correspond 100% to the name of the file + whatever extension is right for your language. So "YourType" should be "YourType.cs", "YourType.vb" or "YourType.whatever" depending on language

score 5 · Answer 2 · answered Mar 18 '11 at 20:13

5

That depends on who you ask.

I, personally, find it easier to read if they are all, always, broken out. However, the compiler doesn't care... so whatever you and your team agree is easier to understand.

answered Mar 18 '11 at 20:13

Jason Whitehorn

13,585
9
54
68

score 1 · Answer 3 · answered Mar 18 '11 at 20:14

In my opinion it's a good practice to avoid that. Some day a developer will be looking around for ClassBar in the project and won't be able to find it easily because it's nested in ClassFoo.cs

Tools like Resharper have a neat feature where you can just select a class, right click, place in new file to make this easier.

If you read any of the popular coding standards (Lance Hunt, iDesign, Framework Design Guidelines etc) most of them advocate 1 class per file.

score 0 · Answer 4 · edited May 23 '17 at 11:47

0

Its annoying to scroll down and search for how many class each.cs file contains/hides.
Maintainability issue while using version control
Usability with our team.

Check here for more interesting discussion on same.

edited May 23 '17 at 11:47

Community

1
1

answered Mar 18 '11 at 20:16

indiPy

7,844
3
28
39

score 0 · Answer 5 · answered Mar 18 '11 at 20:16

I think it was less about whether you can or whether you should. For things like this, I feel it's best to look to the convention in the rest of the codebase. Sometime conformity is better because it makes other developers jobs easier becaues everybody knows where things are.

If it's entirely new project and you are setting the standards here by yourself, do what makes sense to you. To me if the struct has no use outside the related class, I may put them in the same file. Otherwise, I seperate them out.

C#: Un-nested struct in same .cs file as related class?

5 Answers5