Convention for Filenames of Generic Classes [closed]

Question

I want to be able to distinguish between a generic and regular (non-generic) version of a class. Much like the .NET framework does with it's generic and non-generic versions of several of it's interfaces and collection classes. (Queue, Queue(T))

I generally like to follow the convention of one class per file (as in Java). Is there a common convention for naming files containing a single generic class? I'm mostly interested in Windows (NTFS specifically) but it seems like a good convention would be (at least a little) portable.

Underpass

Could you give an example of a class that both a specific and generic type with the same name (which probably isn't a fantastic idea to begin with?) The .NET non-generic types are there for backward compatibility only. – Basset

"Could you give an example of a class that both a specific and generic type with the same name" - you've provided one answer yourself: a class library that needs backwards compatibility! – Fellows

Answer 1

At Microsoft, they use ClassNameOfT.cs.

Tushy

Like this, pretty clear. Although I would probably still name the class the same as the non-generic version. – Seneca

I guess I'd wonder how they would do something like a dictionary. DictionaryOfKT ? – Deist

In the ASP.NET MVC 1.0 source code they use the Dictionary`2.cs convention. – Bywaters

And as mentioned in other places there are known issues in Visual Studio with C# source files with names containing the grave accent. I think that's unfortunate since it follows how they are named through reflection. – Johnny

That's too VisualBasic-y. VB syntax is ClassName(Of T) – Hyperform

ClassName,T.cs is what I use. – Mages

MyClass<TKey, TValue, TConversion, TCallback> -> MyClassOfTKeyOfTValueOfTConversionOfTCallback.cs? – Eladiaelaeoptene

Make sense. Micros Of T – Broome

Answer 2

Just found this question after looking for what conventions other people use for generic class filenames.

Lately I've been using ClassName[T].cs. I really like this convention, and I think it's superior to the others for the following reasons:

• The type parameters jump out at you a little more than they do with the Microsoft convention (e.g., ClassNameOfT.cs).
• It allows you to have multiple type parameters without too much confusion: Dictionary[TKey, TValue].cs
• It doesn't require you to create any special folders, or to have your generic classes in a special namespace. If you only have a few generic classes, having a special namespace dedicated to them just isn't practical.

I borrowed this convention from Boo's generic syntax, albeit slightly modified (Boo uses ClassName[of T]).

Some developers seem to have a phobia of filenames that contain anything but letters and underscores, but once you can get past that this convention seems to work extremely well.

Rochkind

I loved this convention when I first read it, but for some reason some extensions (ahem, CodeMaid) freak out when you have files named using this convention, such as IFoo.cs and IFoo[T].cs. When the extension runs to clean the non-generic document it always affects the generic one instead... Strange behavior. – Introversion

I suspect this convention might be problematic for multi-platform projects. IIRC, [] characters in file names have a special meaning on UNIX-like systems (similar to what they mean in a regex), so using them in file names might force users on UNIX-like systems to escape the file names. – Barnette

Answer 3

I see that this topic has been abandoned more than a year ago, but still I would like to share my view on this convention.

First of all, having multiple classes that have the same name but only differ in the amount of type-parameters isn't always a case of backwards compatibility. Surely, you don't see it very often, but the new Action- and Func-classes of .NET were just designed this way, and I'm currently implementing something similar.

For clarity and distinguishability, I use the following convention that only specifies the number of generic arguments for a given type:

• MyClass.cs
• MyClass.T1.cs
• MyClass.T2.cs

This way, my filenames stay short and simple while still clearly communicating the class-name and the different amount of type parameters at the cost of a simple extra dot (which is, in my experience, a commonly accepted thing to do in a filename and looks much better than comma's and other non-alpanumeric characters, but this is just a matter of taste I guess). Putting the names (or acronyms) of the type parameters just lengthens the filenames while at this level I'm not really interested in the actual names of the type parameters anyway...

Schelling

+1, Really like this! It's simple, short, clear enough / sufficiently informative (at the filename level) and shouldn't trigger too many "symbol-phobians" out there. However as a variant the first dot could be replaced with an underscore for those cases where multiple dots isn't desirable. Or as is the case for me: I use multiple dots for inner classes (unless they are less than ~10lines). So for example: MyClass.InnerClass.cs or an example combined with this for generics MyClass_T2.InnerClass.cs. (I like using dots for inner classes because it mirrors the way they are referenced in code.) – Didactics

This is the only one that satisfied my OCD when it comes to sorting. – Venu

@Didactics You're right but I think an underscore is not the best option to replace the first dot, because the underscore is a valid character in class names (there could be a class named "MyClass_T2") thus possibly creating a conflict. Maybe a dash/minus ?? eg "MyClass-2.InnerClass.cs" – Palanquin

Answer 4

Personally I wouldn't use the grave accent notation:

Foo.cs
Foo`1.cs

For the simple reason that I am scared of the grave accent. Not only does it have a scary name 👻😨😱, but I am unsure how it will be handled by different file systems, version control systems and in URLs. Hence, I would prefer to stick to common alphanumeric characters.

NameOfT.cs seems to be used in ASP.NET Core according to a search on GitHub. 40 results. Reference.

Also used in the .NET Core runtime. 36 results. Reference.

Example:

Foo.cs
FooOfT.cs

Cacophonous

I prefer calling ` a backtick, therefore, it does not have a scary name. – Gervase

Answer 5

Don't use the grave accent ` in your generic file names if you're running Visual Studio 2008. There's a known issue with them that causes breakpoints to fail:

http://connect.microsoft.com/VisualStudio/feedback/details/343042/grave-accent-in-filename-causes-failure-to-recognize-target-language-breakpoints-fail

Pacificas

Answer 6

Sometimes I also see ClassName{T}.cs but it is common to name it ClassNameOfT.cs (like mentioned before Microsoft uses it)

EntityFrameworkCore project(also Microsoft's) uses ClassName`.cs

Iden

I'm not sure why this is downvoted. This is the default setting for the offical stylecop analyzer. As far as I can tell stylecop doesn't even support square brackets for generic class file names. – Terrarium

Answer 7

From the responses so far it seems there isn't a consensus.

Using the same filename in a sub-namespace (and sub-folder) "Generics" (like System.Collecctions.Generics) is an option. But it's not always desirable to create a new namespace.

For example, in an existing namespace with non-generic classes that are maintained for backwards compatibility, but marked with ObsoleteAttribute, it's probably better to keep the generic versions in the same namespace.

I think a suffix is a reasonable way to go. I've adopted a convention of using the type parameters as a suffix (so: MyClassT for MyClass<T>, or MyDictionaryKV for MyDictionary<K,V>.

Fellows

Answer 8

How about:

Type.cs

and

TypeGeneric.cs

Whenever I have done this in the past I have always put both types in one file with the non-generic type as the file name. I think that this makes things pretty clear as .NET has no conventions/restrictions on one type per file like Java does.

But if you must then I would suggest something like I have above, and using a suffix will make the files show up together in any alphabetized list (Solution Explorer, Windows Explorer, etc.).

Here is another idea:

Type`1.cs

This would allow you to break out different generic types by the number of generic type parameters they accepted. Its just a thought though as I still think it would be simpler to just put all the types in one file.

Nocti

Answer 9

All new Microsoft classes use generics. The Queue and ArrayList were there before generics came out. Generics is the way forward.

The convention for one-class-per-single file is to name the filename after the class name (whether generic of not). For MyClass, you'll have MyClas.cs. For every new namespace you'll need to create a new folder. This is how Visual Studio also works.

Raffin

Answer 10

I would probably put them in folders and use the namespace mechanism instead. You can compare with System.Collections vs. System.Collections.Generic. On the other hand, if it's more common than not that the classes use generics, perhaps it's better to point out those that are not. That is if you really want to separate the generic classes from other classes. Personally I usually don't bother to do that, since I don't really see a practical benefit from it.

Fazio

Answer 11

I'd probably have two folders in the project, something like Gereric, NonGeneric or something like that. They can still be in the same namespace, and then they can both have the same file name. Just a thought...

Requite

I personally try to avoid classes in the same namespace in different folders. I like the folder hierarchy to match the namespace hierarchy, for the benefit of tomorrow's developers. – Fellows

Fair enough. I probably would have them in a separate namesapce anyway. Something like MyProj. and MyProj.Generic. – Requite