Live data from Hacker News

How One Missing `var` Ruined our Launch

blog.meloncard.com

171–180 of 223 posts

Re: How One Missing `var` Ruined our Launch

#171

Earlier quoted context omitted.

Now that I understand what you're saying: This is one of the reasons I hate the "feature" in C++ and C99 that you can declare variables anywhere. If you stick to declaring all your variables in one place, it's much easier to notice when you've already used a variable name.

Have you tried the GCC -Wshadow warning flag? It will generate a warning whenever you define a variable with the same name as one declared in an outer scope. Between that, and using -Werror to ensure that warnings never get ignored, I find C99-style declare-anywhere quite useful. It helps me keep the scope of variables limited to the places that need them. That said, I rarely use C99's ability to declare a variable i…

(I'm no C expert, I'm posting my take on this mainly because I'm interested in learning from counterarguments):

Greatgrandparent's error was lack of such inner declaration. -Wshadow wouldn't help with that.

Also, I imagine enforcing old-style declaration restrictions helps you to avoid introducing those errors in first place, but it's just as hard to debug them once they're in.

My choice would be to get in the habit of declaring a variable in the narrowest scope that makes sense. I can't see much of a problem with this (esp. in the context of C!) barring old habit. I don't think Scheme programmers, for example, have this stuff any easier and I don't think scoping is perceived as a problem there.

Re: How One Missing `var` Ruined our Launch

#172
post #152

You will probably get hundreds of comments with unsolocited advice, but let me just say to checkout and setup JSLint: https://github.com/douglascrockford/JSLint Setup and how you use it is more important than just using it. I run it in three places: 1) In my IDE (bound in vim on save, same in TextMate) 2) As a Git checking hook 3) In deployment / build scripts Turn all the warnings way up and it always catches redecl…

I'd love to see them. I'm starting a new job soon and it is going to be pretty much greenfield javascript development all the way. I'm really keen to make sure that I'm ticking every box on the best practices front, right from day one.

Re: How One Missing `var` Ruined our Launch

#173
post #3

Am I right in thinking that the javascript /* "use strict" */ construct would have caught this mistake (just like it would have done for me in perl code)? Seems to me that some such feature is absolutely and utterly necessary in any environment where you're doing a lot of closure creation ..

Yes, though never enable strict mode (in JS) unless you know exactly what it does. `use strict` causes some subtle semantic shifts that can be easily overlooked. For example, there's no dynamic binding between the `arguments` object and a function's arguments:

    ((x)-> x = 2; arguments[0] is 1)(1) # true

    ((x)-> arguments[0] = 2; x is 1)(1) # true

Any developer enabling strict mode should be testing heavily in browsers that actually support the feature. There have been a few high-profile meltdowns already (on BoA, Intel, eBay, etc.) due to devs not understanding the feature, or concatenating a `"use strict"` script (not wrapped in an IIFE) with non-strict code.

JSLint doesn't help matters, as it errors unless `"use strict"` is declared (unless run with the "sloppy" option -- something I'm sure devs love). The absolute worst scenario is for a browser to implement some kind of heuristics-based approach to respect the `"use strict"` prologue; what Brendan Eich calls a "strict quirks mode".

All that said, I'm a big fan of `strict`. It might be a good idea to use it in production, and strip the directives out when deploying.

Re: How One Missing `var` Ruined our Launch

#174
post #75
post #57

Earlier quoted context omitted.

I don't know Coffeescript - does it implicitly create a local var when there is already a global with the same name?

CoffeeScript doesn't allow you to shadow variables in enclosing scopes. The compiler will declare the variable in the "outer-most" scope in which is is used and then any uses in enclosed scopes refer to that one. In this case as long as OP was not using the variable in an enclosing scope, it would have been made local to the function.

This is true for the most part, but there's a subtle edge case. Within a nested function, variables used in loops will redeclare within the inner function:

  ->
    outerVar = "outer"
    ->
      # this will output "undefined" 
      # as CoffeeScript has redeclared it for the loop:
      console.log outerVar 
      0 for outerVar in [0]

Re: How One Missing `var` Ruined our Launch

#176
Melon Card.... I just signed up with a random email and it would allow me to remove the details for that email 'joe.doe@yourwebsite.com'... using your software as long as I did the captcha I could remove records for anyone's email as long as you can find them (the recommendation makes that easy)... you NEED to include verifying the email address before you can perform actions!!

Re: How One Missing `var` Ruined our Launch

#177

Actually it is very easy to debug any javascript error. In IE there is a setting where you can uncheck the Disable Script debugging (Internet Explorer) and in the status bar you will see any javascript error. If you check the checkbox IE will not report any errors. In general during your development you should always uncheck the box.If you double click the javascript status this will exactly report the line number wh…

Yes, These features are there in Firefox can Chrome. You clearly haven't used these browsers. I will suggest you to google for firebug, and developer tools in Chrome.

Re: How One Missing `var` Ruined our Launch

#178
post #75

Earlier quoted context omitted.

CoffeeScript doesn't allow you to shadow variables in enclosing scopes. The compiler will declare the variable in the "outer-most" scope in which is is used and then any uses in enclosed scopes refer to that one. In this case as long as OP was not using the variable in an enclosing scope, it would have been made local to the function.

This is true for the most part, but there's a subtle edge case. Within a nested function, variables used in loops will redeclare within the inner function: -> outerVar = "outer" -> # this will output "undefined" # as CoffeeScript has redeclared it for the loop: console.log outerVar 0 for outerVar in [0]

Huh -- that looks like a (new) bug to me. We should reuse the external declaration.

Re: How One Missing `var` Ruined our Launch

#180

Earlier quoted context omitted.

Node is single-threaded, so yes they are shared. Requests are basically just multiplexed inside the same message loop. In my opinion it wouldn't be quite as scary if js didn't make it so damn simple to accidentally define a global variable (like in this instance, where it was never actually declared in globally-scoped code).

Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.

Well I don't think web browsers are really the same thing as server side code. Even individual pages in a browser are sandboxed from each other. Just like individual request/response cycles for a user session probably should be on the server (unless you go out of your way to break that, ie making some variable "static").
Post reply on HN