4 ms·

no ternary is a smart move tho. makes code more readable for all skill levels.

deckiedan 12y ago
It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single function in 3 or 4 lines, vs the Go style, which can result in extremely long functions (long because they do a few things, and require error checks before and after each one, and so on, rather than being long for actually doing a lot). The single line version implies at the beginning that all the line does is return. The longer version requires you to read the whole paragraph to figure out what it does.
- jlebrech 12y ago
  extra long functions promotes breaking them down into smaller functions.
  - deckiedan 12y ago
    Of course - absolutely. No-one disputes that (seriously). The difference ends up being between a 5 line function, which does 5 simple things, and a 20 line function that does 5 simple things. In my previous example, it was 1 line which returned either the name, or 'New Name', or else 5 lines to do the same. In the end, not a big deal. A matter of taste, rather than judgement, I feel.
    - deckiedan 12y ago
      I suppose one could argue that it's one line actually doing 3 things... but anyway. Not a big deal, at the end of the day.
      - jlebrech 12y ago
        I guess that means you have to move that logic to it's own go file. kinda mimics c in that way.
- sagichmal 12y ago
  > if (data.name != "") { > return data.name > } else { > return "New Data" > } Not exactly... if data.name != "" { return data.name } return "New Data" And consider the likely context... func name(ref int64) string { data, ok := get(ref) if !ok { return "No Data" } if !data.valid { return "Invalid Data" } if data.name == "" { return "New Data" } return data.name } Straightforward and unambiguous.
  - vorg 12y ago
    Doesn't compile though. You'll need lots of extra lines just to see an output, which is really much of what the posted article was talking about with its wandering-eyed gopher tale... package main import "fmt" func main(){ fmt.Println(name(28)) } type T struct{name string; valid bool} func get(ref int64) (T, bool) { return T{"abc", true}, false } func name(ref int64) string { switch data, ok := get(ref); true { case !ok: return "No Data" case !data.valid: return "Invalid Data" case data.name == "": return "New Data" default: return data.name } }
serve_yay 12y ago
It's just syntactic sugar for if-else though, so it's right in the sweet spot of "doesn't make a big difference either way" and "is subject to preference" that makes it a prime target for bikeshedding. Personally I don't like the ternaries either, typically the syntax is ugly, but the if-else seems only slightly better to me.
- Retra 12y ago
  Here's how you should use ternary: return (isblue ? "Blue" : "Red");
  - rootbear 12y ago
    My evil twin wants to do this some day: (pickfunc? func1: func2)(pickarg? arg1: arg2); Works great!
- the_af 12y ago
  It's not syntactic sugar. The ternary operator usually appears in imperative languages (or should I say, languages which are not expression-oriented) where the if-then-else construct statement is NOT an expression, and possibly has side-effects. Therefore, you need an alternative construct that really is an expression and evaluates to something. The syntax itself is irrelevant. If you can say the following in your favorite language: x = if (condition) { something } else { something else } then you don't need a "ternary operator".
wwweston 12y ago
I'm completely baffled that people find the ternary operator difficult to scan. The concept is simple. The syntax can be terse, but it doesn't have to be. Modestly capable Excel users take advantage of something just like it. The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names. And when that's the case, well, you're going to have the same problem with the expressions in your if/else, albeit spread out over a few more lines by convention (which one could do with a ternary expression just as well). I'm at the point where I suspect complaints about the ternary operator are a cargo cult repetition thing, and the developers who are scared of it are scared because they were either taught by someone else to be scared, or they're suffering from a confirmation bias problem where they notice confusing conditionals more when they're associated with the operator.
- hurin 12y ago
  > The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names. It's definitely possibly to write obfuscated ridiculous code without the ternary operator -- but I think that's part of the whole "go-lang mentality". Would I leave unused declarations in production code? No. Do I have a problem with a compiler that doesn't let me test code with a function call commented out without also commenting out all the other variables/functions that are now unused as a result? Yes. > I'm at the point where I suspect complaints about the ternary operator are a cargo cult repetition thing, and the developers who are scared of it are scared because they were either taught by someone else to be scared, or they're suffering from a confirmation bias problem where they notice confusing conditionals more when they're associated with the operator. I definitely don't think Rob Pike and Ken Thompson are getting confused -- it's more like they took a utilitarian view of the situation and decided - if the average code-base is made better or easier to read by this change, then it's worth it. The over-all result is a language that appears to be easy to pick up and productive at least for those who use it - but it's hardly exciting or fun to code in.
- yarrel 12y ago
  It's not a cargo cult thing, it's inherited wisdom borne out by painful experience. Like goto and braceless single-expression blocks they are so easy to misuse that they can easily be much more trouble than they're worth. Simple ternaries can be useful in trading off the unreadability of verbosity for the unreadability of compactness. Real Programmers should know how and when to use them. But nested ternary expressions are basically trolling...

It's a balance between readability meaning 'short, and concise' and readability meaning 'very clear, even if that requires being overly verbose'. return (data.name !== '' ?: 'New Data') or Python style: return (data.name if data.name else 'New Data') vs: if (data.name != '') { return data.name } else { return 'New Data' } The former being much more concise, so that you can display (and grok, perhaps) a single function in 3 or 4 lines, vs the Go style, which can result in extremely long functions (long because they do a few things, and require error checks before and after each one, and so on, rather than being long for actually doing a lot). The single line version implies at the beginning that all the line does is return. The longer version requires you to read the whole paragraph to figure out what it does.

jlebrech 12y ago
extra long functions promotes breaking them down into smaller functions.
- deckiedan 12y ago
  Of course - absolutely. No-one disputes that (seriously). The difference ends up being between a 5 line function, which does 5 simple things, and a 20 line function that does 5 simple things. In my previous example, it was 1 line which returned either the name, or 'New Name', or else 5 lines to do the same. In the end, not a big deal. A matter of taste, rather than judgement, I feel.
  - deckiedan 12y ago
    I suppose one could argue that it's one line actually doing 3 things... but anyway. Not a big deal, at the end of the day.
    - jlebrech 12y ago
      I guess that means you have to move that logic to it's own go file. kinda mimics c in that way.
sagichmal 12y ago
> if (data.name != "") { > return data.name > } else { > return "New Data" > } Not exactly... if data.name != "" { return data.name } return "New Data" And consider the likely context... func name(ref int64) string { data, ok := get(ref) if !ok { return "No Data" } if !data.valid { return "Invalid Data" } if data.name == "" { return "New Data" } return data.name } Straightforward and unambiguous.
- vorg 12y ago
  Doesn't compile though. You'll need lots of extra lines just to see an output, which is really much of what the posted article was talking about with its wandering-eyed gopher tale... package main import "fmt" func main(){ fmt.Println(name(28)) } type T struct{name string; valid bool} func get(ref int64) (T, bool) { return T{"abc", true}, false } func name(ref int64) string { switch data, ok := get(ref); true { case !ok: return "No Data" case !data.valid: return "Invalid Data" case data.name == "": return "New Data" default: return data.name } }

serve_yay 12y ago

It's just syntactic sugar for if-else though, so it's right in the sweet spot of "doesn't make a big difference either way" and "is subject to preference" that makes it a prime target for bikeshedding. Personally I don't like the ternaries either, typically the syntax is ugly, but the if-else seems only slightly better to me.

Retra 12y ago
Here's how you should use ternary: return (isblue ? "Blue" : "Red");
- rootbear 12y ago
  My evil twin wants to do this some day: (pickfunc? func1: func2)(pickarg? arg1: arg2); Works great!
the_af 12y ago
It's not syntactic sugar. The ternary operator usually appears in imperative languages (or should I say, languages which are not expression-oriented) where the if-then-else construct statement is NOT an expression, and possibly has side-effects. Therefore, you need an alternative construct that really is an expression and evaluates to something. The syntax itself is irrelevant. If you can say the following in your favorite language: x = if (condition) { something } else { something else } then you don't need a "ternary operator".

wwweston 12y ago

I'm completely baffled that people find the ternary operator difficult to scan. The concept is simple. The syntax can be terse, but it doesn't have to be. Modestly capable Excel users take advantage of something just like it. The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names. And when that's the case, well, you're going to have the same problem with the expressions in your if/else, albeit spread out over a few more lines by convention (which one could do with a ternary expression just as well). I'm at the point where I suspect complaints about the ternary operator are a cargo cult repetition thing, and the developers who are scared of it are scared because they were either taught by someone else to be scared, or they're suffering from a confirmation bias problem where they notice confusing conditionals more when they're associated with the operator.

hurin 12y ago
> The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names. It's definitely possibly to write obfuscated ridiculous code without the ternary operator -- but I think that's part of the whole "go-lang mentality". Would I leave unused declarations in production code? No. Do I have a problem with a compiler that doesn't let me test code with a function call commented out without also commenting out all the other variables/functions that are now unused as a result? Yes. > I'm at the point where I suspect complaints about the ternary operator are a cargo cult repetition thing, and the developers who are scared of it are scared because they were either taught by someone else to be scared, or they're suffering from a confirmation bias problem where they notice confusing conditionals more when they're associated with the operator. I definitely don't think Rob Pike and Ken Thompson are getting confused -- it's more like they took a utilitarian view of the situation and decided - if the average code-base is made better or easier to read by this change, then it's worth it. The over-all result is a language that appears to be easy to pick up and productive at least for those who use it - but it's hardly exciting or fun to code in.
yarrel 12y ago
It's not a cargo cult thing, it's inherited wisdom borne out by painful experience. Like goto and braceless single-expression blocks they are so easy to misuse that they can easily be much more trouble than they're worth. Simple ternaries can be useful in trading off the unreadability of verbosity for the unreadability of compactness. Real Programmers should know how and when to use them. But nested ternary expressions are basically trolling...