Template parameter naming

[dmikis]

There've been a discussion around our current naming rules for templates. @vmit suggests (IIUC) to adopt a rule that will allow to distinguish a template parameter in code.

The main concern is naming conflicts for constrained template parameters, i.e. the ones required to extend a type or implement a interface:

interface StyleExtractor<S extends Style> {
    (...args: any[]): S;
}

Here's S is a violation of our style guide. But it's difficult to come up with an alternative since the most sane one is Style but it's already taken:( In this particular example we can rename Style in import statement, but that's not a universal solution.

During discussion we've looked at some other codebases and code styles to gather more input. Here's the findings:

1. STL seems to use rules analogous to ours;
2. Java suggest to always name generic parameter with a single letter (but there're several violations of this rule in the JDK);
3. Google's Java style guide suggests to either use single letter names or append T to name of a parameter (but the one for C++ doesn't);
4. after quick glance TSC itself seems to use somewhat Hungarian notation, either just T, U, etc or TType.

[dfilatov]

I'd vote for TType notation cause it:

• explicitly declares there's a template parameter
• doesn't introduce ugly single-letter naming, especially for multiple parameters

[ikokostya]

I like Google's Java style guide with ending T (e.g. FooT)

• it looks nice
• avoid name conflicts with interfaces (StyleT extends Style)
• and easy to read as Foo Type

Leading T looks awkward, but consistently with other notations with leading letters, e.g. I for interfaces. Of course, if we decided to use them.

[dmikis]

After some consideration I've ended up preferring Google's option too. My motivation is that TFoo is a clear homage to Hungarian notation and adopting that approach will raise a (rather incovinient:) question: why not do that everywhere. Whereas FooT may be considered as shortened version of FooType which makes sense for generic parameters.

[vmit]

I'm fine with the T postfix too

[dmikis]

The PR was met with some friction. My understanding is that we have a consensus on necessity of suffix or prefix, we just need to choose one. Since that choice is purely stylistic I suggest we vote for it.

To make it easy we'll do that with comment reactions. React with 👍 to vote for TGenericParamter and 👎 for GenericParameterT.

Motivation for TGenericParameter:

Looks more consistently with IInterface if a project chooses to adopt it and with prefix _ for private and protected properties.

Motivation for GenericParameterT:

Easily reads as Generic Parameter Type, don't suggest usage of Hungarian notation (which we try to avoid).

/cc @dfilatov @ikokostya @vmit @makishvili @tarmolov @dodev @twoRoger

[ikokostya]

Why need explicitly specify that name is template parameter?

[dmikis]

Why need explicitly specify that name is template parameter?

My best understanding is that it's convenient to distinguish them from all the other types in a module. However, adding something to a parameter name gives as a simple and reliable naming scheme that avoids conflicts.

[ikokostya]

After thinking some time, I can't make decision. I don't like required prefix or suffix for template parameters, but it can be used as ad hoc solution for original problem:

interface StyleExtractor<StyleType extends Style> { ... }

// or

interface StyleExtractor<TStyle extends Style> { ... }

So, for now I vote for don't specify this rule in style guide.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.