12

I'm trying to understand what the convention is for placement of C# and/or C++ structs within a project. In it's own source file? If yes, are there any conventions that I should make a habit of following?

In first year, the conventions weren't really discussed, but generally, we "stuck" the struct wherever it was being used or "felt" most relevant...

In my particular case, I have a couple of structs explicitly made up of value types which are going to be passed throughout the particular application and it's classes, so I can't definitely say that any one particular "area" can claim any sort of ownership.

afuzzyllama
  • 6,275
  • 5
  • 42
  • 61
Ray
  • 1,304
  • 2
  • 17
  • 36
  • 1
    Do you really need that many C# structs? Structs are uncommon in C#. – R. Martinho Fernandes Sep 19 '11 at 23:12
  • 1
    Conventions will vary from company to company, so it's pretty subjective. Typically, a struct should have it's own code file, arranged in a sensible folder hierarchy. Unless the struct is internal to a particular class; then have that struct as a private one inside the class where it is being used. – EtherDragon Sep 19 '11 at 23:56
  • @ R. Martinho: The number of structs is exactly two, which contain only basic value types. These structs don't require any of the functionality of class, and this approach seems to follow convention. I agree with what you are saying fundamentally of course! – Ray Sep 21 '11 at 18:58

4 Answers4

7

A small struct that relates solely to a single class is often put in the same file as that class. Similarly, a small simple class that is used within a single class is often put in the same file. This identifies that the item relates to a specific class and is means of grouping it with that class.

Any struct that isn't both simple (has only a handful of values) and specific to a single class should be in its own file.

Kirk Broadhurst
  • 25,044
  • 13
  • 91
  • 149
  • 2
    Any struct that isn't simple should be a class. Adding all those gotchas for either little benefit or negative benefit (depending on how you view stack/heap usage) should be avoided. – JRoughan Sep 20 '11 at 00:19
5

In C++, if the struct is "owned" by a certain class or interface or the like, then I prefer to declare it as an inner type to what owns it. If the struct is a common protocol that many different classes make use of, then I put it in its own .h file. If the struct is one of a related suite of small-ish structs, then I make a namespace for such things and declare all the structs within a single .h file that provides that namespace.

In C# I would probably do the equivalent as in C++.

Forer
  • 1,035
  • 1
  • 7
  • 32
fluffy
  • 4,460
  • 28
  • 58
4

You should be able to just create a separate file for each struct or each group of related structs (I'd recommend one per struct, but sometimes that gets tedious - if you group them make sure to name it thoughtfully).

If the project is large enough to have "areas" as you call them, then it would probably be smart to introduce one or more namespaces for the structs that appropriately describe them. This will prevent naming collisions and give your code-using clients a way to remember what's where. Having to qualify names can seem painful sometimes, but its important in large projects and does help in the end.

Lastly, most larger projects have a Common folder in either a high level directory or in the location where their message interfaces are defined. This is important so everyone can recognize that location holds data structures which should be used by all to keep a clear, consistent interface to avoid the need for lots of conversion code which can be time consuming and costly (and usually ends up being replicated too!).

John Humphreys - w00te
  • 32,140
  • 30
  • 125
  • 230
1

If the structure is used across multiple classes, I put it in its own file. Stylecop doesn't complain either way. And reshaper has a re-factoring to move a struct to its own file.

Josh
  • 2,180
  • 3
  • 21
  • 24