what's the status of the official naming convention for TypeScript?

[zpdDG4gta8XKpMCd]

This is an offshoot of the question I asked here: #5453 (comment)
Since it doesn't really fit the original topic I want to take it out of there, so:

Reading the answer I got an impression that a sort of a convention already exists de facto, and it's somewhat natural to, say, name type parameters using capital letters.

I am not questioning the need in or a purpose of a naming convention or any other standard that does good to clarity and unification. It won't be a surprise to say that there are a lot of people like me who are looking for it. What I am wondering is:

• What is the status of the convention that the design team uses? Is it considered mature and recommended for general use? Does it account for all existing and upcoming features of the language?
• If so, what makes it such? Is it one-that-fits-all sort of recommendation? Is it equally good for OOP and FP programming styles? Is it comprehensive enough to be used as a reference for establishing internal coding standards on TypeScript projects just like the convention for C# is?
• If no, what is the current take on that?

[RyanCavanaugh]

I think there are two broad categories of rules here.

First are recommendations internal to our own team that we don't intend to foist onto others and for which we don't claim any particular broad suitability. The compiler doesn't use classes as a stylistic matter, for example, so we don't have any private fields by which to establish a convention. Obviously we find these rules adequate for our own uses, and they're not totally specific to writing a compiler, but even when teams within Microsoft ask for style guidelines, we don't necessarily give them as a starting point.

Second are recommendations that help to elucidate more general concepts. For example, I will always tell people that "Prefix all interfaces with I" is a bad rule, because interface in TypeScript means something rather different from in C# or Java, and I don't want to encourage muddying those waters. But I wouldn't discourage someone from writing interface IComparable<T> { when writing an interface intended for implementsing by classes. Conversely, "Type parameters should be capital letters" is a very common pattern in languages with templating or generics, so following that convention makes sense (I would find it very odd to find a function written compare<t, u>(X: t, Y: u).

So it would probably make a lot of sense for us to sort out those two buckets and clarify which conventions we believe to be broadly applicable vs those that are esoteric to our own codebase. Writing out the justifications for those general recommendations would also be useful as an informative device.

As a postscript, homogeneity in these things can be a giant catch-22. I remember a bad bug (0.9.1?) that only affected functions inside modules where the function name was the same as the contaning module name -- for which, in over a million lines of partner code, we had zero hits because everyone was following a ModuleName.functionName convention.

[kruncher]

I am quite fond of the convention used in C# for generic type parameters because they are self-documenting and do not leave one guessing at what the abbreviated letter means:

https://blogs.msdn.microsoft.com/kcwalina/2004/11/03/design-guidelines-update-names-of-generic-type-parameters/

[RyanCavanaugh]

I think #878 is the resolution of this discussion