4 ms·

Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clea

by geuis 16y ago

Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clearer, and faster for me to understand the "evt = evt || window.event" than it is to trace through all of those if() statements. I used to be the opposite, I couldn't understand the short form or how it worked. Ternaries confused the hell out of me for a while. Why? Because when I look at "evt = evt || window.event", my mind has learned about the conditionals that each of these represent. Its analogous to phrases that mean different things in different contexts. "That guy has balls", for example. So I look at it and I know that "if( evt )" is the same as "evt ? true:false" as "if( typeof evt !== 'undefined' ). I know that in the context of that statement, evt || window.event is saying "if evt exists, use that. if not, use window.event". So the reason its confusing to people is they haven't learned all of the different things the shorter code means. For me, after having spent many, many hours writing javascript I find the short form easier to understand and less tiring. Not only that, in raw numbers it just saves space. Now, the other lesson I've learned over the years is that many times it is much better to start out writing in plain old "if" statements. Get the logic right, then reduce it down. There's nothing more annoying than trying to debug someone else's poorly written code. And for god's sake, DOCUMENT!

sesqu 16y ago
I've got to agree here. The short form is great for those ubiquitous "set if null" pieces of code, but you wouldn't want to use one for a complex conditional. The advantage comes in when you recognize the intent from the way it's formulated, and so don't have to trace the syntax. If your clause is something like "y%4==0 && (y%100!=0 || y%400==0)", you may want the long form, even for null y. I feel the example return statement is pushing it. Additionally, it only works if you can trust that what is written is what is intended - which can be a problem with the gotchas in the truthiness system. If you aren't sure what type the input will have, you'll want the explicit checks, and if you don't have a helper function, those can drag on long enough to make it unreasonable to expect the reader to see the guard pattern. All in all, I consider the short form a form of self-documenting code. If your readers don't find it easy to get used to, it becomes obfuscation. YMMV.
wmwong 16y ago
I agree that in some cases, guards, defaults and ternaries flow more naturally. However, I feel that there's a contradiction. You say that it is easier to understand but have learned to write them in plain old "if" first because it's better. It's easier to get it wrong if you write it shorthand. If it's better to start writing them in "if", doesn't that mean it's easier to understand? If it is easier to use guards, defaults, and ternaries, you shouldn't have to resort to plain "if" to get the logic right. And I agree, DOCUMENT!
- scott_s 16y ago
  We sometimes use if-else statements to write out some straight-up logic because we don't understand it at first. So we build it from the ground up. If, after writing it all out with primitives, we realize "Oh, it's just this anded with this and ored with that" then we actually understand the problem. Put another way: if you write a boolean expression as a sequence of statements, my assumption is you don't really understand what you're doing.
Confusion 16y ago
I've been doing this long enough that its is easier, clearer, and faster for me to understand However, are you also the only one reading the code? If not: is it also easier, clearer and faster to understand for the other ones? On the one hand, they may learn fast when reading code that uses these constructions. On the other hand: perhaps it only sinks in over time and they won't learn fast enough to properly maintain such code.
gruseom 16y ago
And for god's sake, DOCUMENT! What clarity would documentation add to this example?
- konad 16y ago
  // I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code // TODO think harder
  - gruseom 16y ago
    I'm guessing you must be joking?
    - konad 16y ago
      I'm trying to elicit a wry smile from those who understand but those comments describe the OP. It's a cute trick, useful in shell scripts but not serious code where readability should trump cute & terse. When I clicked the title I too was expecting some kind of method dispatch. Lets get some ternaries in there too a && b || c ? (d || e) && f : f && d || h;
      - angusC 16y ago
        Did you read the entire article?
        konad 16y ago
        Yes, it's the sort of thing every programmer goes through on the road to enlightenment
        angusC 16y ago
        You said "I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code" In addition to talking about ternaries, guards and defaults, the article discusses myriad techniques aimed at replacing conditional logic with entirely non-conditional approaches (both functional and oop).These include function dispatching, function delegation, use of high order functions, functions as data and polymorphism. These techniques aren't going to work for everyone and it would be very cool if you chimed in with your own experiences. What's not cool is misrepresenting the article.

by geuis 16y ago

sesqu 16y ago

I've got to agree here. The short form is great for those ubiquitous "set if null" pieces of code, but you wouldn't want to use one for a complex conditional. The advantage comes in when you recognize the intent from the way it's formulated, and so don't have to trace the syntax. If your clause is something like "y%4==0 && (y%100!=0 || y%400==0)", you may want the long form, even for null y. I feel the example return statement is pushing it. Additionally, it only works if you can trust that what is written is what is intended - which can be a problem with the gotchas in the truthiness system. If you aren't sure what type the input will have, you'll want the explicit checks, and if you don't have a helper function, those can drag on long enough to make it unreasonable to expect the reader to see the guard pattern. All in all, I consider the short form a form of self-documenting code. If your readers don't find it easy to get used to, it becomes obfuscation. YMMV.

wmwong 16y ago

I agree that in some cases, guards, defaults and ternaries flow more naturally. However, I feel that there's a contradiction. You say that it is easier to understand but have learned to write them in plain old "if" first because it's better. It's easier to get it wrong if you write it shorthand. If it's better to start writing them in "if", doesn't that mean it's easier to understand? If it is easier to use guards, defaults, and ternaries, you shouldn't have to resort to plain "if" to get the logic right. And I agree, DOCUMENT!

scott_s 16y ago
We sometimes use if-else statements to write out some straight-up logic because we don't understand it at first. So we build it from the ground up. If, after writing it all out with primitives, we realize "Oh, it's just this anded with this and ored with that" then we actually understand the problem. Put another way: if you write a boolean expression as a sequence of statements, my assumption is you don't really understand what you're doing.

Confusion 16y ago

I've been doing this long enough that its is easier, clearer, and faster for me to understand However, are you also the only one reading the code? If not: is it also easier, clearer and faster to understand for the other ones? On the one hand, they may learn fast when reading code that uses these constructions. On the other hand: perhaps it only sinks in over time and they won't learn fast enough to properly maintain such code.

gruseom 16y ago

And for god's sake, DOCUMENT! What clarity would documentation add to this example?

konad 16y ago
// I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code // TODO think harder
- gruseom 16y ago
  I'm guessing you must be joking?
  - konad 16y ago
    I'm trying to elicit a wry smile from those who understand but those comments describe the OP. It's a cute trick, useful in shell scripts but not serious code where readability should trump cute & terse. When I clicked the title I too was expecting some kind of method dispatch. Lets get some ternaries in there too a && b || c ? (d || e) && f : f && d || h;
    - angusC 16y ago
      Did you read the entire article?
      - konad 16y ago
        Yes, it's the sort of thing every programmer goes through on the road to enlightenment
        angusC 16y ago
        You said "I don't like the keyword "if" so I'm hiding it with && and || because I haven't thought deep enough about a better way of structuring my code" In addition to talking about ternaries, guards and defaults, the article discusses myriad techniques aimed at replacing conditional logic with entirely non-conditional approaches (both functional and oop).These include function dispatching, function delegation, use of high order functions, functions as data and polymorphism. These techniques aren't going to work for everyone and it would be very cool if you chimed in with your own experiences. What's not cool is misrepresenting the article.