3 ms·

You see the problem though, I need to try it and practice it to see how simple and clear it is. I can write code that I can easily understand. I can write terse

You see the problem though, I need to try it and practice it to see how simple and clear it is. I can write code that I can easily understand. I can write terse, clever code that I can easily understand. But I want to write code so that the next person can also easily understand it. More importantly, code that's easier to understand has less chance of getting buggy when it inevitably gets rfactored or extended. >and it's dramatically more compact Why do I want that?

munchbunny 8y ago
Compactness and readability are related, in the sense that your working memory also works somewhat in terms of lines of code. There's a natural trade-off in the sense that in order to make something more compact, you have to rely on the context to provide whatever information you remove. For example, the ternary pattern of chaining ?:'s. You have to be used to it. However, once you know it, the more compact pattern works fairly well.
naasking 8y ago
> You see the problem though, I need to try it and practice it to see how simple and clear it is. You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table. > Why do I want that? To add to the other poster: the more context you can fit on your screen, the less scrolling, jumping you need to do to understand a program's behaviour. Compactness that doesn't sacrifice readability speaks for itself. The code sample we're discussing is compact and very readable.
- macspoofing 8y ago
  >It literally takes 5 seconds to understand the idiom I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. In fact, it is obviously so confusing that to make it work someone suggested the introduction of white-space and multiple lines, as follows: return (a < b) ? -1 : // a smaller (a > b) ? 1 : // a greater 0; // equal And they still got it subtly wrong, because the semantics of their 'fix' makes it seem like it is the equivalent of: if(a < b) return -1; else if(a > b) return 1; else return 0; which isn't quite true. It's actually: if(a < b) return -1; else if(a > b) return 1; else return 0; Will this make a difference in this case? No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code.
  - naasking 8y ago
    > It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. I disagree. The ternary version is much easier to read than your if-else. If-else statements can feature compound statements and side-effects where the ternary version is simpler because it only returns a value. There are fewer corner cases to consider. > It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. It adds no complexity. It's significantly easier to understand than if-else. > which isn't quite true. It's actually: Right, there's literally no semantic difference between those two. > No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code. You really don't. There's nothing special to consider, no corner cases. It's literally condition-on-left-value-on-right.
  - deleted 8y ago
    [deleted]
  - Technetium_Hat 8y ago
    But those two pieces of code are parsed exactly the same way in most languages--the only difference is the newline between `else` and `if`

munchbunny 8y ago

Compactness and readability are related, in the sense that your working memory also works somewhat in terms of lines of code. There's a natural trade-off in the sense that in order to make something more compact, you have to rely on the context to provide whatever information you remove. For example, the ternary pattern of chaining ?:'s. You have to be used to it. However, once you know it, the more compact pattern works fairly well.

naasking 8y ago

> You see the problem though, I need to try it and practice it to see how simple and clear it is. You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table. > Why do I want that? To add to the other poster: the more context you can fit on your screen, the less scrolling, jumping you need to do to understand a program's behaviour. Compactness that doesn't sacrifice readability speaks for itself. The code sample we're discussing is compact and very readable.

macspoofing 8y ago
>It literally takes 5 seconds to understand the idiom I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. In fact, it is obviously so confusing that to make it work someone suggested the introduction of white-space and multiple lines, as follows: return (a < b) ? -1 : // a smaller (a > b) ? 1 : // a greater 0; // equal And they still got it subtly wrong, because the semantics of their 'fix' makes it seem like it is the equivalent of: if(a < b) return -1; else if(a > b) return 1; else return 0; which isn't quite true. It's actually: if(a < b) return -1; else if(a > b) return 1; else return 0; Will this make a difference in this case? No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code.
- naasking 8y ago
  > It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. I disagree. The ternary version is much easier to read than your if-else. If-else statements can feature compound statements and side-effects where the ternary version is simpler because it only returns a value. There are fewer corner cases to consider. > It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. It adds no complexity. It's significantly easier to understand than if-else. > which isn't quite true. It's actually: Right, there's literally no semantic difference between those two. > No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code. You really don't. There's nothing special to consider, no corner cases. It's literally condition-on-left-value-on-right.
- deleted 8y ago
  [deleted]
- Technetium_Hat 8y ago
  But those two pieces of code are parsed exactly the same way in most languages--the only difference is the newline between `else` and `if`