5 ms·

I disagree with claim that One letter generics are a bad habit. In my opinion, it is proper to use one letter generics but start with A then B, then C... so it

I disagree with claim that One letter generics are a bad habit. In my opinion, it is proper to use one letter generics but start with A then B, then C... so it enables to reason about generics positionally. Pseudo example of this: `map<A,B>(fn:(el:A)=>B):B[]`

jgwil2 6y ago
I think I agree with you (though I would favor T, U, V as the sequence). What would the alternative look like in what you wrote? In and Out? Range and Domain? Generic type variables are often too abstract to give a sensible name to. This is the one "bad habit" that I think is a bit silly - naming conventions can vary by project.
- SmellyPotato22 6y ago
  In the context I am thinking about, writing a generic iterator, you have 0 context of the what the concrete types will ever be.
MrPatan 6y ago
Do you also use one letter variables and parameters? If not, what is different about generics? Even in your example, I'd rather read this: map<IN,OUT>(fn:(el:IN)=>OUT):OUT[] Plus, it really is a habit. If you stop doing it for these kind of examples that really are very generic, maybe people wouldn't also use only one letter for cases where there is more of a difference between them.
- SmellyPotato22 6y ago
  Kinda gets a little hairy if you start to add more types. Example: `//fork :: [a] ->((a -> b ), (a -> c)) -> ([b] ,[c])` `fork<A,B,C>(fn1:(el:Iterator<A>)=>B,fn2:(el:Iterator<A>)=>C)`
  - MrPatan 6y ago
    What would be the opposite of "fork", something like "zip" that gets two lists and combines them into one? Would it have a signature also starting like this: `zip<A, B, C>(...`
    - SmellyPotato22 6y ago
      I think that about right. Although I think this is slightly different than regular zip which is [a] -> [b] -> [(a,b)] and instead would be ([a],[b]) -> [c] or if I remember currying right [a] -> [b] -> [c].
- legerdemain 6y ago
  > Do you also use one letter variables and parameters? A question in response to your question... Do you ever give an ALL CAPS name to a class? Why not? Maybe it's the set of conventions I'm used to, but I find T, U, V familiar and IN, OUT jarring and dramatically less readable at a glance.
  - MrPatan 6y ago
    I use ALL_CAPS in generics so they are easy to tell apart from functionNames and ClassNames
  - Dylan16807 6y ago
    It might be 'jarring' but looking over the original line I didn't parse what those types were doing at all, and T/U/V wouldn't be any better, while IN/OUT I can understand without explicitly thinking about it.
- Kranar 6y ago
  Sometimes I do, sometimes I don't. If it's an iterator I often use one letter names such as i, j, k. Similarly if it's a generic unbounded type I also give it a one letter name.
brundolf 6y ago
Hard disagree. Having come into a TS codebase from the outside that made liberal use of generics, they can make things incredibly difficult to follow if they don't have really good naming and/or docs.
- Garlef 6y ago
  Yes. But do long names even help? I imagine, in such a project the system of generics can be so complex that a new dev cannot use them to their intent without completely understanding the code.
  - brundolf 6y ago
    You could say the same thing about variable names: "But do long names even help? I imagine, in such a project the system of logic can be so complex that a new dev cannot use them to their intent without completely understanding the code." Meaningful names help a person gain an understanding of the code. And that's not even getting into whether or not "completely understanding the code" is a tractable goal in the first place (I don't think it is, even for the people who wrote the code, much less those who come later)
    - Kranar 6y ago
      Long variable names don't help either. It's been mostly a stylistic choice and a recent trend that stylistically long variable names are nice. But there are plenty of projects that use short variable names or even one letter names, and I don't see any evidence that those projects are less productive because of it. The actual research is that long variable names make it harder to understand code. It makes the variable name become an integral part of any code snippet that a reader feels compelled to memorize the specific names used, and that memorization results in errors and increased recall time. Short variable names, including single letter names, allow a reader to basically ignore the name itself which allows them to accurately memorize an entire chunk of code without feeling the need to memorize long names. This improves recall time. In simpler terms, when a snippet of code uses descriptive variable names your brain is inclined to believe that those names matter and that you need to remember them, compared to short variable names that your brain will not have to bother remembering and instead frees you up to focus on the structure and semantics of the code snippet. The study that you can read, which is quite insightful is here: https://pdf.sciencedirectassets.com/271600/1-s2.0-S0167642309X00055/1-s2.0-S0167642309000343/main.pdf https://pdf.sciencedirectassets.com/271600/1-s2.0-S016764230... Note that long function names DO help, but long variable names do not. That said, feel free to use long variable names if that's what you like and your project does it that way. Don't, however, express that as some kind of extensively studied software engineering principle that has research backing it. It's basically one of those things someone decided was true and everyone else just decided to believe it without ever doing the kind of work needed to validate the hypothesis. In software engineering, we are still in the days of Aristotle, where we simply believe things to be true because we want them to be true. Just like the days of Aristotle I wouldn't be surprised if it takes us literally thousands of years before someone comes along and decides to question and test basic assumptions we all take for granted.
notapenny 6y ago
I wouldn't agree they're a bad habit either, but only when used with care. Types like T, and K, V might be as clear to most people as i and j in array operations. Your example is clear enough because the signature is simple, but in more complex functions I've found that becomes obscure real fast, particularly if types are then passed down to something which also uses generic types. Enabling people to reason about things is not as clear as actually telling them what it is. If the 2nd of 3 generic types is the return type for whatever reason, call it SomethingReturn type and remove that ambiguity.
valand 6y ago
Agree, generic name should mirror its meaning. For generic that doesn't have any specific meaning we can use T. Adding a meaning to meaningless generic will add confusion, like in the example, Element might conflict with HTMLElement while it can be something else entirely.

jgwil2 6y ago

I think I agree with you (though I would favor T, U, V as the sequence). What would the alternative look like in what you wrote? In and Out? Range and Domain? Generic type variables are often too abstract to give a sensible name to. This is the one "bad habit" that I think is a bit silly - naming conventions can vary by project.

SmellyPotato22 6y ago
In the context I am thinking about, writing a generic iterator, you have 0 context of the what the concrete types will ever be.

MrPatan 6y ago

Do you also use one letter variables and parameters? If not, what is different about generics? Even in your example, I'd rather read this: map<IN,OUT>(fn:(el:IN)=>OUT):OUT[] Plus, it really is a habit. If you stop doing it for these kind of examples that really are very generic, maybe people wouldn't also use only one letter for cases where there is more of a difference between them.

SmellyPotato22 6y ago
Kinda gets a little hairy if you start to add more types. Example: `//fork :: [a] ->((a -> b ), (a -> c)) -> ([b] ,[c])` `fork<A,B,C>(fn1:(el:Iterator<A>)=>B,fn2:(el:Iterator<A>)=>C)`
- MrPatan 6y ago
  What would be the opposite of "fork", something like "zip" that gets two lists and combines them into one? Would it have a signature also starting like this: `zip<A, B, C>(...`
  - SmellyPotato22 6y ago
    I think that about right. Although I think this is slightly different than regular zip which is [a] -> [b] -> [(a,b)] and instead would be ([a],[b]) -> [c] or if I remember currying right [a] -> [b] -> [c].
legerdemain 6y ago
> Do you also use one letter variables and parameters? A question in response to your question... Do you ever give an ALL CAPS name to a class? Why not? Maybe it's the set of conventions I'm used to, but I find T, U, V familiar and IN, OUT jarring and dramatically less readable at a glance.
- MrPatan 6y ago
  I use ALL_CAPS in generics so they are easy to tell apart from functionNames and ClassNames
- Dylan16807 6y ago
  It might be 'jarring' but looking over the original line I didn't parse what those types were doing at all, and T/U/V wouldn't be any better, while IN/OUT I can understand without explicitly thinking about it.
Kranar 6y ago
Sometimes I do, sometimes I don't. If it's an iterator I often use one letter names such as i, j, k. Similarly if it's a generic unbounded type I also give it a one letter name.

brundolf 6y ago

Hard disagree. Having come into a TS codebase from the outside that made liberal use of generics, they can make things incredibly difficult to follow if they don't have really good naming and/or docs.

Garlef 6y ago
Yes. But do long names even help? I imagine, in such a project the system of generics can be so complex that a new dev cannot use them to their intent without completely understanding the code.
- brundolf 6y ago
  You could say the same thing about variable names: "But do long names even help? I imagine, in such a project the system of logic can be so complex that a new dev cannot use them to their intent without completely understanding the code." Meaningful names help a person gain an understanding of the code. And that's not even getting into whether or not "completely understanding the code" is a tractable goal in the first place (I don't think it is, even for the people who wrote the code, much less those who come later)
  - Kranar 6y ago
    Long variable names don't help either. It's been mostly a stylistic choice and a recent trend that stylistically long variable names are nice. But there are plenty of projects that use short variable names or even one letter names, and I don't see any evidence that those projects are less productive because of it. The actual research is that long variable names make it harder to understand code. It makes the variable name become an integral part of any code snippet that a reader feels compelled to memorize the specific names used, and that memorization results in errors and increased recall time. Short variable names, including single letter names, allow a reader to basically ignore the name itself which allows them to accurately memorize an entire chunk of code without feeling the need to memorize long names. This improves recall time. In simpler terms, when a snippet of code uses descriptive variable names your brain is inclined to believe that those names matter and that you need to remember them, compared to short variable names that your brain will not have to bother remembering and instead frees you up to focus on the structure and semantics of the code snippet. The study that you can read, which is quite insightful is here: https://pdf.sciencedirectassets.com/271600/1-s2.0-S0167642309X00055/1-s2.0-S0167642309000343/main.pdf https://pdf.sciencedirectassets.com/271600/1-s2.0-S016764230... Note that long function names DO help, but long variable names do not. That said, feel free to use long variable names if that's what you like and your project does it that way. Don't, however, express that as some kind of extensively studied software engineering principle that has research backing it. It's basically one of those things someone decided was true and everyone else just decided to believe it without ever doing the kind of work needed to validate the hypothesis. In software engineering, we are still in the days of Aristotle, where we simply believe things to be true because we want them to be true. Just like the days of Aristotle I wouldn't be surprised if it takes us literally thousands of years before someone comes along and decides to question and test basic assumptions we all take for granted.

notapenny 6y ago

I wouldn't agree they're a bad habit either, but only when used with care. Types like T, and K, V might be as clear to most people as i and j in array operations. Your example is clear enough because the signature is simple, but in more complex functions I've found that becomes obscure real fast, particularly if types are then passed down to something which also uses generic types. Enabling people to reason about things is not as clear as actually telling them what it is. If the 2nd of 3 generic types is the return type for whatever reason, call it SomethingReturn type and remove that ambiguity.

valand 6y ago

Agree, generic name should mirror its meaning. For generic that doesn't have any specific meaning we can use T. Adding a meaning to meaningless generic will add confusion, like in the example, Element might conflict with HTMLElement while it can be something else entirely.