views:

124

answers:

4

I am trying to stick to general naming conventions such as those described in Design Guidelines for Developing Class Libraries. I put every type into its own source file (and partial classes will be split across several files as described in question Naming Conventions for Partial Class Files), using the name of the type as the file name.

Examples:

namespace Demo.Bla                         //  project
{
    enum FlowDirection { }                 //  in file FlowDirection.cs
    class LayoutManager { }                //  in file LayoutManager.cs
}

namespace Demo.Bla.LayoutControllers       //  folder LayoutControllers in project
{
    class StackPanelLayoutController { }   //  in file LayoutControllers/StackPanelLayoutController
}

But I am not sure I've come up with a clever way of naming source files which contain generic classes. Say that I have following classes, for instance:

namespace Demo.Bla.Collections             //  folder Collections
{
    class Map<T> { }                       //  in file Map.cs (obviously)
    class Bag { }                          //  in file Bag.cs (obviously)
    class Bag<T> : Bag { }                 //  also in file Bag.cs ???
}

Should I put the code of both the non-generic and the generic Bag classes into the same Bag.cs file? What are your habits?

+4  A: 

Usually if I have several types "overloaded" by the number of type parameters, it's either because one derives from the other or one is used to create the other. I just put them in the same file.

One alternative option would be to split them into different files, make one file the "primary" one, and the others "depend" on it in the build file, as per the partial class question you linked to in the question.

That way you could end up with a visual link in Visual Studio, but still one class per file to make it easier to work with them.

Jon Skeet
A: 

I add a suffix 'T' to the names of my generic classes.

class Bag { }                           // in file Bag.cs 
class BagT<T> : Bag { }                 // in file BagT.cs
class BagInputs : BagT<Input>           // in file BagInputs.cs

You asked,

Should I put the code of both the non-generic and the generic Bag classes into the same Bag.cs file? What are your habits?

The above convention of mine is non-standard; I should clarify that I was answering "what are my habits" and not necessarily "what you should do".

ChrisW
That seems somewhat unusual to my mind. What would you have done if you were designing the `Tuple` types in .NET 4?
Jon Skeet
@Jon - Yes, unusual: I use some non-standard naming conventions, not necessarily quite like the naming conventions of the .NET library types. I haven't met those `Tuple` types before, but I guess I would have called them all `TupleT` in the same `TupleT.cs`.
ChrisW
@ChrisW - Interesting; thanks for the idea, but I do not like it very much. It does not fit with of all other generic types used in .NET (`List<int>` would become `ListT<int>` which feels really awkward to me).
Pierre
+3  A: 

I think the common solution to this problem is to name the file like this:

{ClassName}`{NumberOfGenericParameters}

This would give you this filename:

Bag.cs and Bag`1.cs

This is the way Microsoft handle this issue in frameworks like Asp.net Mvc.

Mattias Jakobsson
@Mattias - Oh, I had not realized that the backtick is a legal character in file names (on Windows, at least). So this means that any generic type should have a backtick and a number in its name. Hmmm, I'll have to think this over. Thanks.
Pierre
@Pierre, Yes. This is how I solve the issue. However, when I have only the generic class and no non generic version I usually don't put the back-tick character in the filename. So in your case I would have the generic Map class in a file named "Map.cs".
Mattias Jakobsson
+1  A: 

I have seen some libraries using

Bag.cs
Bag`1.cs
Bag`2.cs

as this is what the Type.Name would display.

I want to be more descriptive with the type parameters so I lately tend to use

Bag.cs
Bag{T}.cs
Bag{TKey, TValue}.cs

This is a format that is also supported by the XML comments.

/// <summary>
/// ...
/// Uses the <see cref="T:MyLibrary.Bag{TKey, TValue}" /> class.
/// </summary>
herzmeister der welten
@herzmeister der welten - Thank you for the suggestion. I like the idea of putting the type parameters directly into the file name better than the shorter back-tick + number naming scheme.
Pierre