Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Of parser-fetishists and semi-colons

christianheilmann.com

Post reply on HN
Print view View original

101–110 of 125 posts

Re: Of parser-fetishists and semi-colons

#101

Post by wahnfrieden »

quanticle wrote: post #81
wahnfrieden wrote: post #63

Earlier quoted context omitted.

As a counterpoint, we decided to with underscored_names for our JS since we work with a lot of serialized Python data structures via JSON and using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON and things defined in the JS. We're not writing reusable libraries for other projects to use, and we don't use a heavy amount of 3rd p…

"using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON" Couldn't that almost be viewed as a feature, rather than a bug? I mean, this way you can instantly tell if a particular variable was received from the server via JSON or was defined in the client code itself. I would consider a naming distinction like to be a benefit, rathe…

Hm, how is that generally valuable to know? Maybe in certain use cases but for us that would just be noise.

Re: Of parser-fetishists and semi-colons

#102

Post by radicalbyte »

ajross wrote: post #92
radicalbyte wrote: post #84

Earlier quoted context omitted.

Thanks, I get it now :) So the second operand can be a function / method, with any (or no) return type. > function bob () { alert("bob") }; true && bob(); Alerts "bob". Nice trick, though not something I'd personally ever us as it's not concise and isn't portable to C# (and I assume Java/C++). Plus using the IF statement is a better showing of intent.. and I don't really like relying on job security through obscurity…

It is concise. There are fewer tokens and bytes needed to write A && B than if ( A ) { B }. And the intent thing is, as I've tried to explain, very much situation-specific. There are many programmers out there very comfortable with this idiom. That it doesn't happen to be popular in the web development community doesn't mean it sucks or isn't worth learning. Don't pass judgement on syntax you literally just learned,…

I'm not judging it, I'm just saying that it's not something I'd use because it's confusing for my colleagues / anyone maintaining my work. Unless they're a pure Javascript person.

It is a neat trick though, and proof that I need to spend a little more time hacking in javascript to improve my knowledge :-)

Re: Of parser-fetishists and semi-colons

#103

Post by lucian303 »

This is ridiculous. Twitter's developers are lazy.

You don't NEED a semicolon for the interpreter, you NEED a semicolon for the other readers/users of your code!!!

That goes for all other code practices that enhance readability. If you disagree that human readability is less important than interpreter/compiler, you're a lazy moron.

Period.

Re: Of parser-fetishists and semi-colons

#105

Post by artsrc »

radicalbyte wrote: post #80
tlogan wrote: post #25

Earlier quoted context omitted.

I think you missed the point. This is not really about whether semicolons are required or not. The point is that in order to ensure maintainability of code you should try to use language (and framework) in a way which ensures better maintainability, supportability, and portability of your code. Look, the statement like "a && b" is 100% valid in many languages but in order to increase maintainability, supportability,…

Okay, I'm going to bite. && is logical AND, and it operates on boolean expressions (or types). So "a && b" evaluates to true if both a and b are true. How can that be replaced by "if(a){b;}"? Is it "r = a && b" being replaced by "if(a){r=b}"? Using Chrome's javascript console: > a = "asdas"; b="da"; a == b; false > a = "asdas"; b="da"; if(a) { b }; "da" Could you (or some other javascript expert) explain it to me?

Going the other way: In languages where if is an expression

    if (a) { b; }
would return b if a was true and nothing otherwise. Which is a similar to a && b.

Re: Of parser-fetishists and semi-colons

#106

Post by chris_wot »

tptacek wrote: post #61
brown9-2 wrote: post #60

Earlier quoted context omitted.

I think it's so boring because it's a one-sided debate. One side chooses a style that they find aesthetically-pleasing even if it causes issues for some small subset of potential users. The other side is flabbergasted that someone would be so reckless and argues for the sensible, safe option, which requires simply terminating your lines of code with an extra character, making those few issues for a small subset of po…

Oh for fuck's sake.

I understand the frustration with this comment, but the clincher for me on the whole anti semi-colon crowd was at this article:

http://www.wordsbyf.at/2011/10/31/i-dont-write-javascript/

He says he doesn't use semicolons, except that it caused issues for those who concatenation scripts so he adds a semicolon to the end of the js file. But, lo! This causes issues for those who use the following pattern:

  (function() {
     // Le code
  })()
This has the potential to cause syntax errors when you execute two anonymous functions after each other. Instead of adding a semi-colon to the end, he "works around" the issue by abusing JavaScript like so:

  !function() {
    // Le code
  }()
For fucks sake indeed!

Re: Of parser-fetishists and semi-colons

#107

Post by chris_wot »

philipjrose wrote: post #79
luser001 wrote: post #74

Earlier quoted context omitted.

Unless I'm mistaken 'do_something_else()' won't get executed if toggleClass() returns a value that evaluates to true. Because of short-circuit boolean evaluation.

That's correct. You could use: !isActive && ($parent.toggleClass('open'), do_something_else()) but I don't think anyone would advise it.

Actually, you are all missing Crockford's real point, which is that they are considering making ! a binding deference of function objects. If they do, then this:

  clearMenus()
  !isActive && $parent.toggleClass('open')
Becomes this:

  clearMenus()!isActive && $parent.toggleClass('open');
And not this:

  clearMenus();
  !isActive && $parent.toggleClass('open');
The no semi-colon crowd is ridiculous. There are no good arguments for omitting semicolons!

Re: Of parser-fetishists and semi-colons

#109

Post by tptacek »

dclowd9901 wrote: post #71
tptacek wrote: post #13

Anyone else think this is by far the most boring technical debate ever to hit HN?

Because all you see it as is an argument about syntax. It's actually an argument between the old guard and the up-and-coming hotshots. Nobody really cares one way or another, and while it would take Twitter more time to append changes to their code than it would Crockford, my guess is the trouble for either would be negligible. That said, this is very obviously a pride war between those who stick to convention and th…

It is just an argument about syntax.

Re: Of parser-fetishists and semi-colons

#110

Post by nemetroid »

bzbarsky wrote: post #90
radicalbyte wrote: post #80

Earlier quoted context omitted.

Okay, I'm going to bite. && is logical AND, and it operates on boolean expressions (or types). So "a && b" evaluates to true if both a and b are true. How can that be replaced by "if(a){b;}"? Is it "r = a && b" being replaced by "if(a){r=b}"? Using Chrome's javascript console: > a = "asdas"; b="da"; a == b; false > a = "asdas"; b="da"; if(a) { b }; "da" Could you (or some other javascript expert) explain it to me?

In JavaScript, && does not evaluate to a boolean. It evaluates to the thing on the left if that thing is false (in which case the right hand side is not evaluated at all), otherwise to the thing on the right. So in said JavaScript console, "asdas" && "da" evaluates to "da" and "" && "da" evaluates to "". So in an assignment context |r = a && b| would need to be replaced by: if (a) { r = a } else { r = b }, which may…

Nitpick: you mean `if (!a) {r = a} else {r = b}` (or switched blocks).
Post reply on HN