Hacker News Reader

Comment by untog | Hacker News Reader

Reminds me of one of the more confusing bugs I've ever encountered in my life. I was throwing together a quick UI with Adobe Flex, and for some reason every time you clicked a particular button, the entire UI would shift 20 or so pixels to the right. I spent hours scratching my head until I noticed this for loop:

    for (x=0;x<variable.length;x++) {
    // blah
    }

I wasn't declaring the x variable, so it was using the x part of the x/y positioning of the UI container. Woops.

edit: initialise/declare brain freeze

View on HN

Ha, that reminds me of a program I was writing in MATLAB. I used `i` for a loop index in one part of the script and then later when doing some complex number calculations (`2 + 3i`)...it was one of those so-stupid-you-have-to-laugh moments when I finally figured it out.

It's for this precise reason that I use 1i rather than i when doing complex arithmetic in matlab.

Wait... matlab allows "AB" to be inferred as "A*B"? How is that not a disaster? Parsing a token that doesn't even exist in the lexer stream? Even C++ wouldn't try that.

1i is special, sort of like 1d or 1f in C. The i refers to the imaginary number datatype. i also can be reassigned, which is a horrible design bug in Matlab.

Now there's an argument for syntax highlighting.

It also doesn't happen in languages where you must say self.x to access a property/field called x.

Exactly my first thought: "This wouldn't happen with Python".

Only for case of instance variable. Python still has nested function, non-instance variable, and implicit declaration.

Only it is worse in Python because, lacking `var` keyword, you will shadow the variable in Python

I wasn't initialising the x variable

Do you mean s/initialising/declaring/, or am I just really confused?

Yes, sorry, I meant declaring. Wrote that post in a hurry as I headed out the door, I wasn't paying too much attention.

Hmm, so you wrote a careless typo while describing your "careless" coding? Not to be harsh, but maybe it's a hint?

Well if you really want to go into painful detail about it, I had originally phrased the sentence differently, something along the lines of "leaving out the var in the for loop initialisation". It wasn't very readable so I changed it, but the word 'initialise' was on my mind.

In any case, I'm not sure that I need a hint to tell me that doing things quickly and carelessly is a bad idea. But we all do it sometimes, in both our programming and our writing.

Well sure. I actually wasn't trying to be harsh OR sarcastic. It's not pop psychology (I think it goes back to Freud) that in some sense there are no mistakes. We all make errors and I was just saying that two errors about the same issue might be a hint that one has "issues" about the, er, issue or that some self-sabotage in important matters might surface under stress. You're the only one can answer that. I admire your courage in sharing your experience with all these crack programmers.

Not to sound harsh, followed by something quite sarcastic and judgemental isn't a particularly nice way to address someone you don't know.

I for one would speculate, not to sound harsh, that if you haven't made silly errors like this then you haven't been around the block enough times.

I think you misinterpreted my remark. This actually wasn't a "silly" error, it was, as many have pointed out, an avoidable error. I think many don't take javascript seriously and it bites them.

> I for one would speculate, not to sound harsh, that if you haven't made silly errors like this then you haven't been around the block enough times.

on the other hand, those of us who have been around the block enough times have almost certainly encountered co-workers who were bright, talented, cute, whatever - but at the end of the day were just ... sloppy ... lazy ... careless ... in their approach. It's a personality thing - they had nice childhoods, they never learned to by hyper-vigilant and paranoid, and as a consequence... they write buggy code that can't be trusted.

"...never learned to by hyper-vigilant..."

My eyebrow just raised so far my forehead cramped.

Muphry's law.

I'm contemptuous of his coding practice, not his writing or grammar. His writing is pleasant to read... but so what? where are the multiple layers of defense standing between a simple syntactical or semantic error and a full scale business-impacting technical fuck up. that is what I meant by being vigilant and paranoid.

I'd be offended if it wasn't for the fact that your original accusation appears to be that I had had a happy childhood. I'll take that one on the chin.

As for the rest... well, I don't understand where you're going with it. Pop psychology aside, are you really suggesting that you write utterly seamless code every single time? You've never done a build and then realised that you made an error somewhere along the way, gone back and fixed it? You act as if my mistake had the potential to ruin a business. Of course it didn't- I picked up on it before the code had even been pushed to the remote repository.

You can live in a world where everyone does everything perfectly, every time (and pay the price when you inevitably don't) or you can set up systems with unit testing, user testing, and- yes- developer testing that results in bugs being dealt with in a timely manner before a single end-user sees anything.

But hey, each to their own. Whatever works for you. If you get it right first time, every time, then you are a better programmer than I, and I congratulate you on it.

>>You act as if my mistake had the potential to ruin a business. Of course it didn't- I picked up on it before the code had even been pushed to the remote repository.

Not to beat on you, but didn't you discover the error after users started using it in a big news day?

He means declaring.

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.

And much easier to wind up with lots of bad dead code or worse, reusing variables over and over leading to tightly coupled code. IMHO, variables should be declared as closely as possible to where they're used in the smallest scope possible. C languages do it right.

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 in the middle of a block. I primarily use the C99 feature of declaring variables as part of a loop.

(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.

I agree with you entirely that -Wshadow (or an equivalent for JavaScript) would not solve the problem reported in the original article. However, it does solve the problem cperciva mentioned in the comment I replied to: "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.". -Wshadow detects when you've already used a variable name and reports that as a warning (or an error if you use -Werror, which you should).

I also agree about declaring a variable in the narrowest scope that makes sense. I often see code that attempts to reuse the same variable for several different purposes, rather than declaring separate variables in narrower scopes.

Umm, I find the opposite to be true. By always declaring variables where I use them (notably in for loops), I avoid accidentally reusing a variable I used elsewhere.

That is a special case. Loop headers should be considered the top of scope blocks in C. I don't know why the language designers didn't do that.

They did, in C99.

That makes variables scope over far more than they need to, opening up a pretty frequent bug avenue of using the wrong variable that you did not intend to use.

Classic! I did that with rotation in my js gaming engine once, fun times.

exactly what happened to me. I had two for loops defined in my JS code which used the variable "i" without declaring. Hence, when the code ran, the second for loop behaving weirdly. It took sometime before catching the bug.

PHP experience can poison development in other languages.

Reply on news.ycombinator.com