5 ms·

I think calling your generic type 'Element' is a bad choice -- that's shadowing a built-in type (https://developer.mozilla.org/en-US/docs/Web/API/Element https:

I think calling your generic type 'Element' is a bad choice -- that's shadowing a built-in type (https://developer.mozilla.org/en-US/docs/Web/API/Element https://developer.mozilla.org/en-US/docs/Web/API/Element) and it makes the code confusing to read at a glance. That's one thing I like about T, it's very self evident that it's just 'the' generic type. But maybe I'm just used to it. With multiple generic types I can see how longer names would be useful.

hooksfordays 6y ago
Agreed. I think naming generic types makes the most sense with multiple types, or when more specific names make sense. For example, if a generic argument must inherit from a certain type: `class SomeView<ViewState extends BaseViewState>` or some such. `Element` is as non-descriptive as `T` in the author’s example and, IMO, doesn’t add any tangible benefit.
endgame 6y ago
And often in parametric code, there is nothing you can say about the types you're working with.
- danbolt 6y ago
  I write C++ for a living, and one thing I've kind of noticed a similar thing to what you've mentioned. "very generic" template code often is best left to a name such as T, but a very specialized piece of metaprogramming often benefits from specific naming. The latter scenario being that hopefully the person debugging your logic a decade from now has some insight into what you were thinking, namely.
munchbunny 6y ago
I think of “T” as the template parameter the same way I think of “i” as a loop iterator. It’s a conventional shorthand, so if it’s contextually clear, like if T is the only template parameter and there aren’t complex constraints on how T behaves, there isn’t much harm in using it for succinctness.
ducharmdev 6y ago
I like the convention in C# where you prepend generic type names with a T, clearly signifying that it's a generic while being more descriptive. E.g.: public delegate TResult Func<in T,out TResult>(T arg);
- eitland 6y ago
  On the contrary as someone who moves somewhat comfortably between Java, C# and TypeScript projects the tendency to use especially I in front of interfaces but also other letters in front of other things are an explicit pain point. (Java has others like just like how every time you open a Gradle project you can expect someone has invented yet another unique way of structuring build files for this repo. :)
  - DaiPlusPlus 6y ago
    Even without its basis in the history of COM, the I-prefix for interfaces types in .NET makes sense because interfaces-types are very structurally and semantically different to "a type's interface" - so having some way to quickly distinguish them at-a-glance is necessary. I started off in .NET and when I was using Java it wasn't immediately obvious what types were interfaces or not (e.g. "List" is an interface in Java, and also especially when the interface suggests what the implementation is). C# can be described as a considerably better Java - but I wish they didn't inherit Java's interfaces vs. classes model and instead had something that enables some form of structural-typing: something like TypeScript's interfaces or Swift's protocols.
    - eitland 6y ago
      I too enjoy C# a lot and find Typescript close to perfect (obviously it is constrained by its relation to Javascript past, present and future). That said, a bit more about why the I feel the I convention is unneeded and even a problem: - If one doesn't use a powerful IDE when using either C#, Java or even Typescript there is a fair chance one is doing something wrong. (I allow for exceptions for people who are so insanely smart that they need the lack of support as a brake for their brains ;-) Powerful IDEs can tell you just fine what is a class and what is an interface. - In what I think of as well written Java projects (and C# many projects for that matter) you'll often feel what is an interface and what is a list just by the name anyway: Javas List that you mention is a perfect example: List is the general concept of a List in Java. ArrayList, LinkedList etc are implementations of that. Once you get used to this convention it is hard to even recognize it until you sit down and try to explain it to someone.) - Contrary, prefixing with I (typical .Net style) or suffixing with Interface (something I've seen in older Java projects) these days[1] encourages lazy naming and unnecessary duplication: If there is only one interface, just write a class and let the interface be implicit. Especially in Java, but also in C# and Typescript refactoring is so trivial (unless you are changing an external API that other people already depend on) that you can just create an interface with the same name and rename the class later if you need it; there's no reason to worry about it up front. [1]: "these days" added as a qualifier since it used to be that certain older systems required you to write one or more interfaces for each class.
deleted 6y ago
[deleted]
MaxBarraclough 6y ago
On a similar note, I'd avoid naming a property type.
xixixao 6y ago
Some codebases prefer `TItem` - the preceding T signifies that this is a type variable, not a type, which is quite helpful when reading type signatures.
seanwilson 6y ago
> That's one thing I like about T, it's very self evident that it's just 'the' generic type. Code that has more characters just takes longer to read over and process as well e.g. having to mentally match up which variable names are the same and spotting patterns. Yes, use descriptive names where it helps which is the vast majority of the time, but for small functions where from context it's obvious e.g. `i` can be better than something like `customerReportIndex`, as well as your T example for a general type. Maths proofs would be tiring to read with long names for all the variables for example.
steve_taylor 6y ago
My side-project convention is all-caps, e.g. ELEMENT. No underscores. Always one word. It looks like a generic parameter and its name conveys meaning. It really helps when there are multiole generic parameters.
lalaithion 6y ago
It's like writing fn square(numberToBeSquared : number): number { return numberToBeSquared * numberToBeSquared; } The one letter variable version of the function is perfectly readable. Most generics aren't used in a significantly complicated way. Sure, maybe if you're doing something like Haskell's lenses, then you should use descriptive names might be better, but how often are you writing type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t and is type Lens source dest gettable settable = forall structure. Functor structure => (gettable -> structure settable) -> source -> structure dest really any easier to read?
- scns 6y ago
  The second Lens version is way easier to read IMO
  - lalaithion 6y ago
    Thanks for providing this feedback - now I'm glad I actually bothered to write it all out, because while I was doing that I was thinking to myself "This is going to be nonsense to anyone who doesn't already understand the first one".
- Aeolun 6y ago
  Either is really, really hard to read, but I suspect that’s more haskell and the code itself than the naming.
  - seanparsons 6y ago
    If you think that's hard don't look at the types for any moderately complicated JavaScript project.
SkyPuncher 6y ago
Yea, that one felt like my college professors getting caught up on single letter variables as loop controls. When I see a lower case single letter, I assume either a loop control or an enumerator var. When I see an upper case single letter, it's a generic.
Vinnl 6y ago
I use a simple rule: if I can understand what it does in a code review, I won't call it out. If I don't, then the name is probably too terse. Most of the time, T is just fine.

hooksfordays 6y ago

Agreed. I think naming generic types makes the most sense with multiple types, or when more specific names make sense. For example, if a generic argument must inherit from a certain type: `class SomeView<ViewState extends BaseViewState>` or some such. `Element` is as non-descriptive as `T` in the author’s example and, IMO, doesn’t add any tangible benefit.

endgame 6y ago

And often in parametric code, there is nothing you can say about the types you're working with.

danbolt 6y ago
I write C++ for a living, and one thing I've kind of noticed a similar thing to what you've mentioned. "very generic" template code often is best left to a name such as T, but a very specialized piece of metaprogramming often benefits from specific naming. The latter scenario being that hopefully the person debugging your logic a decade from now has some insight into what you were thinking, namely.

munchbunny 6y ago

I think of “T” as the template parameter the same way I think of “i” as a loop iterator. It’s a conventional shorthand, so if it’s contextually clear, like if T is the only template parameter and there aren’t complex constraints on how T behaves, there isn’t much harm in using it for succinctness.

ducharmdev 6y ago

I like the convention in C# where you prepend generic type names with a T, clearly signifying that it's a generic while being more descriptive. E.g.: public delegate TResult Func<in T,out TResult>(T arg);

eitland 6y ago
On the contrary as someone who moves somewhat comfortably between Java, C# and TypeScript projects the tendency to use especially I in front of interfaces but also other letters in front of other things are an explicit pain point. (Java has others like just like how every time you open a Gradle project you can expect someone has invented yet another unique way of structuring build files for this repo. :)
- DaiPlusPlus 6y ago
  Even without its basis in the history of COM, the I-prefix for interfaces types in .NET makes sense because interfaces-types are very structurally and semantically different to "a type's interface" - so having some way to quickly distinguish them at-a-glance is necessary. I started off in .NET and when I was using Java it wasn't immediately obvious what types were interfaces or not (e.g. "List" is an interface in Java, and also especially when the interface suggests what the implementation is). C# can be described as a considerably better Java - but I wish they didn't inherit Java's interfaces vs. classes model and instead had something that enables some form of structural-typing: something like TypeScript's interfaces or Swift's protocols.
  - eitland 6y ago
    I too enjoy C# a lot and find Typescript close to perfect (obviously it is constrained by its relation to Javascript past, present and future). That said, a bit more about why the I feel the I convention is unneeded and even a problem: - If one doesn't use a powerful IDE when using either C#, Java or even Typescript there is a fair chance one is doing something wrong. (I allow for exceptions for people who are so insanely smart that they need the lack of support as a brake for their brains ;-) Powerful IDEs can tell you just fine what is a class and what is an interface. - In what I think of as well written Java projects (and C# many projects for that matter) you'll often feel what is an interface and what is a list just by the name anyway: Javas List that you mention is a perfect example: List is the general concept of a List in Java. ArrayList, LinkedList etc are implementations of that. Once you get used to this convention it is hard to even recognize it until you sit down and try to explain it to someone.) - Contrary, prefixing with I (typical .Net style) or suffixing with Interface (something I've seen in older Java projects) these days[1] encourages lazy naming and unnecessary duplication: If there is only one interface, just write a class and let the interface be implicit. Especially in Java, but also in C# and Typescript refactoring is so trivial (unless you are changing an external API that other people already depend on) that you can just create an interface with the same name and rename the class later if you need it; there's no reason to worry about it up front. [1]: "these days" added as a qualifier since it used to be that certain older systems required you to write one or more interfaces for each class.

deleted 6y ago

[deleted]

MaxBarraclough 6y ago

On a similar note, I'd avoid naming a property type.

xixixao 6y ago

Some codebases prefer `TItem` - the preceding T signifies that this is a type variable, not a type, which is quite helpful when reading type signatures.

seanwilson 6y ago

> That's one thing I like about T, it's very self evident that it's just 'the' generic type. Code that has more characters just takes longer to read over and process as well e.g. having to mentally match up which variable names are the same and spotting patterns. Yes, use descriptive names where it helps which is the vast majority of the time, but for small functions where from context it's obvious e.g. `i` can be better than something like `customerReportIndex`, as well as your T example for a general type. Maths proofs would be tiring to read with long names for all the variables for example.

steve_taylor 6y ago

My side-project convention is all-caps, e.g. ELEMENT. No underscores. Always one word. It looks like a generic parameter and its name conveys meaning. It really helps when there are multiole generic parameters.

lalaithion 6y ago

It's like writing fn square(numberToBeSquared : number): number { return numberToBeSquared * numberToBeSquared; } The one letter variable version of the function is perfectly readable. Most generics aren't used in a significantly complicated way. Sure, maybe if you're doing something like Haskell's lenses, then you should use descriptive names might be better, but how often are you writing type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t and is type Lens source dest gettable settable = forall structure. Functor structure => (gettable -> structure settable) -> source -> structure dest really any easier to read?

scns 6y ago
The second Lens version is way easier to read IMO
- lalaithion 6y ago
  Thanks for providing this feedback - now I'm glad I actually bothered to write it all out, because while I was doing that I was thinking to myself "This is going to be nonsense to anyone who doesn't already understand the first one".
Aeolun 6y ago
Either is really, really hard to read, but I suspect that’s more haskell and the code itself than the naming.
- seanparsons 6y ago
  If you think that's hard don't look at the types for any moderately complicated JavaScript project.

SkyPuncher 6y ago

Yea, that one felt like my college professors getting caught up on single letter variables as loop controls. When I see a lower case single letter, I assume either a loop control or an enumerator var. When I see an upper case single letter, it's a generic.

Vinnl 6y ago

I use a simple rule: if I can understand what it does in a code review, I won't call it out. If I don't, then the name is probably too terse. Most of the time, T is just fine.