Live data from Hacker News

Hide this in your coworkers' JavaScript code tomorrow

gist.github.com

21–30 of 40 posts

Re: Hide this in your coworkers' JavaScript code tomorrow

#21

On a related note, I got a pleasent surprise when I opened the Developer Console on Facebook.com: they present you with a giant red warningp[1] and block any code execution in it until you explicitly 'allow [your] account to be hijacked if I paste malicious Javascript'[2] [1]: http://i.imgur.com/6UVaTen.png [2]: https://www.facebook.com/selfxss

I like what MDN does: https://dl.dropboxusercontent.com/u/9161524/Capture2.PNG

BTW, that warning is starting to drive me nuts.

Re: Hide this in your coworkers' JavaScript code tomorrow

#22
post #7

One of my favourite ways to punish JavaScript developers who don't use `var` is to randomly hide a if (false) { var GLOBALVAR; } somewhere in the code. It's fun (in a harmless fun kinda way, but you can also use some really dirty tricks to really hamper someone's work) to fuck up people's code - that's why I wrote Underhanded JavaScript. :P EDIT: Another fun one is to add `return`s to constructor functions.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

I'm not too sure either. In JS, block scoping does not exist. There are only function scopes, so the var declaration gets hoisted out of the if block (but the assignment occurs in the if block - so the assignment doesn't happen).

Re: Hide this in your coworkers' JavaScript code tomorrow

#23
post #7

One of my favourite ways to punish JavaScript developers who don't use `var` is to randomly hide a if (false) { var GLOBALVAR; } somewhere in the code. It's fun (in a harmless fun kinda way, but you can also use some really dirty tricks to really hamper someone's work) to fuck up people's code - that's why I wrote Underhanded JavaScript. :P EDIT: Another fun one is to add `return`s to constructor functions.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

Imagine you have inexperienced coders who do this:

    function foo() { 
        bar = function(){}; //define bar
    }

    function baz() {
        bar(); // use bar
    }
Note that both foo() and baz() could themselves, be inside another function. Doesn't really matter. Now `bar` is a defined as a a property of the global object.

If you add

    if (false) {
        var bar;
    }
in baz(), most developers, as I had noticed, will ignore it - afterall, it's a false condition, the code will never enter that branch. But because variables are "hoisted", you have now declared `bar`, it's lexically scoped as a new variable under `baz()`, with the value `undefined`.

So, when `bar()` gets called, it becomes an error, because `undefined` is not a function definition.

...

and yes, dear JavaScript developers, despite all the good efforts of people like Nicholas Zakas, Douglas Crockford, Addy Osmani and the like, bad JavaScript still exists in the wild. And I feel, in greater numbers than ever, and I am not optimistic that the amount of bad JavaScript will be ever reduced. This depresses me. Can't be helped, I guess.

Re: Hide this in your coworkers' JavaScript code tomorrow

#24
post #12
post #9

There's the old C prank: #define true false .. but in reality, I had a serious issue with Qt once: #ifndef TRUE #define TRUE true #define FALSE false #endif Now this screwed up some other library's similar definitions...

Logic inversion should normally be caught rather easily, flow control misdirections not so much : #define if while . My favorite (C++) : #define private public

My favorite (C++) : #define private public

Unless I'm mistaken, C++ was (deliberately) specified in such a way that such a redefinition does not affect the behavior of (most) already valid code. Access control doesn't affect overload resolution, for example.

I had to add the (most) qualifier because I bet dynamic_cast and other RTTI mechanisms would achieve different runtime results against some classes if private inheritance became public.

Also, I believe that C++ forbids preprocess munging of keywords under penalty of undefined behavior if you include any standard headers, so anything could happen in most modules.

Re: Hide this in your coworkers' JavaScript code tomorrow

#25
post #7

One of my favourite ways to punish JavaScript developers who don't use `var` is to randomly hide a if (false) { var GLOBALVAR; } somewhere in the code. It's fun (in a harmless fun kinda way, but you can also use some really dirty tricks to really hamper someone's work) to fuck up people's code - that's why I wrote Underhanded JavaScript. :P EDIT: Another fun one is to add `return`s to constructor functions.

How is either of those fun? I see why revere console logs are funny, if done when there is no time pressure and a lot of time available.

I do not want to work in environment where people feel that it is appropriate to routinely "punish" colleges by making them waste time like this.

Re: Hide this in your coworkers' JavaScript code tomorrow

#26
post #25
post #7

One of my favourite ways to punish JavaScript developers who don't use `var` is to randomly hide a if (false) { var GLOBALVAR; } somewhere in the code. It's fun (in a harmless fun kinda way, but you can also use some really dirty tricks to really hamper someone's work) to fuck up people's code - that's why I wrote Underhanded JavaScript. :P EDIT: Another fun one is to add `return`s to constructor functions.

How is either of those fun? I see why revere console logs are funny, if done when there is no time pressure and a lot of time available. I do not want to work in environment where people feel that it is appropriate to routinely "punish" colleges by making them waste time like this.

You could argue that "use strict" does the same, except it's language mandated. But yes, you have a point. These are not particularly fun, if you are on the receiving end. I've seen more than enough hair-raising bad JavaScript to last me a lifetime.

But you gotta admit, if you're on the pranking end, it could be fun to see someone tear their hair out.

Or my sense of humour is way out of whack. probably the latter

Re: Hide this in your coworkers' JavaScript code tomorrow

#27
post #7

One of my favourite ways to punish JavaScript developers who don't use `var` is to randomly hide a if (false) { var GLOBALVAR; } somewhere in the code. It's fun (in a harmless fun kinda way, but you can also use some really dirty tricks to really hamper someone's work) to fuck up people's code - that's why I wrote Underhanded JavaScript. :P EDIT: Another fun one is to add `return`s to constructor functions.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

It is only harmful if the developer actually used the variable as a side effect, aka relied on it outside the current scope.

By making the global variable local to the scope around the if statement, side-effects won't escape the local scope (as said, the if block does not declare a new scope).

Re: Hide this in your coworkers' JavaScript code tomorrow

#28

Earlier quoted context omitted.

I haven't had my morning coffee; can you explain what this breaks? I know JavaScript's scoping rules are unusual.

I'm not too sure either. In JS, block scoping does not exist. There are only function scopes, so the var declaration gets hoisted out of the if block (but the assignment occurs in the if block - so the assignment doesn't happen).

Oh you can definitely fake block scoping in JavaScript, with ES5. ;P

Re: Hide this in your coworkers' JavaScript code tomorrow

#29
This is pretty hilarious, would drive me nuts.

I once did a similarly annoying chrome extension just for fun: https://chrome.google.com/webstore/detail/annoying-typo-gene...

Randomly generates typo in inputs and text boxes.

Side note: Mihai, since I know you will be reading this, watch out if your arrays in LRTF are upside down ;)

Post reply on HN