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]
When you consider Facebook's target audience, it's probably okay to make people like us jump through a hoop in order to stop Grandma from being completely p0wned by typing in some JavaScript.
Yes, maybe people should know that running arbitrary JavaScript is dangerous, but they don't.
By the way, we're going to penalize April Fools' jokes tomorrow so that they fall off the front page quickly. This isn't new, but we're going to be more systematic about it. The April 1 tech thing has become stale. If you guys see April Fools stories that we miss, flag them unless they're really particularly good.
People complain about HN's humorlessness, and they're right to a point. The trouble is that with a culture of humor comes a flood of lame humor. HN wants to optimize for intellectual curiosity, which wants higher signal/noise ratio. It's not that we're killjoys—we like jokes and laughing—it's that the signal/noise problem is hard.
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.
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
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.
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).
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).
I did something similar in high school. You dropped a file named "System.java" into a Java project, which then intercepted all calls to System.out.println() and, for example, printed the text backwards, very slowly, or googled the text in Firefox:
A silly prank, but it makes me wonder: has anyone implemented an antivirus/anti-problem scanner for open source code? i.e. scan the source code on a git repository and report any suspicious code that matches known malicious patterns? Lint, but targeted at detecting likely security flaws and code injections.
Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution. I guess you could try to limit the tool to a list of established projects but that of course limits the effectiveness of what you're trying to do. Established projects may be more attractive as a delivery vector due to widespread adoption, but there's also more eyes looking at the code giving a potentially higher chance of discovery of any exploits. And new projects have less-deployment and potentially more active contributors who might more easily catch some exploit slipped in.
Then there's the problem that you've got how many languages you need to scan against? And no quick way to determine what language a project is implemented in? Sure, you could add some sort of language detection in there but then you're adding to the overhead.
Finally, if the project has any sort of real complexity, some of the best areas to exploit would be in the integrations between two technology surfaces. Writing a tool to look for problems in a single contained module is one thing, writing a tool that can find problems in the interfaces between modules is quite a bit more complicated.
I think your "anti-problem" scanning tool would be the best avenue to pursue though. Maybe some sort of tool that would run on "checkin/pull-request" and look for issues like introduced buffer-overflow potential and things like that.
I think it's just easier to rely on solid projects with "known" contributors to police themselves and hope for the best, as bad as that may sound. Still, if you could create such a tool you'd make a fortune and improve the world immensely, so don't let my nay-saying stop you.
> Sounds incredibly resource intensive. First, the sheer number of "open-source" projects which grow whenever someone has a new idea or some frustration with an existing solution.
You should totally tell that to TravisCI, I bet they'd like to know. =)
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.
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.
Perhaps it doesn't change the implementation, but I know I've used the above trick to get access to private functions for unit testing (yes, yes, I know you "should" only test interfaces, or make internal tests; spare me and realize it's useful: http://mrzechonek.github.io/tut-framework/faq.html#can-we-te...)
Yes kill your coworker's productivity by making her or him even more miserable when dealing with a bug. If you did this and I was your manager, at worst you'd end up on a PIP. If you want conduct a prank do something that doesn't frustrate the work they're paid to do.
Making the text print out in reverse is cute because they should be expected to have a "WTF?" second and then move on. I would expect that messing with the printed order of elements would backfire badly.
[1]: http://i.imgur.com/6UVaTen.png
[2]: https://www.facebook.com/selfxss