Javascript quiz · Perfection kills
 

Небольшой тест:
http://perfectionkills.com/javascript-quiz/

Ответил на 11 из 14. Честно-честно :)
Ошибся в #7, #12, #14

Бредятина. Смысла во многих строчках нет.

Например?

PeaceCoder имеет в виду, что вместо того, чтобы стандарт зубрить, лучше бы фреймворки селекторов писали ;)

:D

Это уже не стандарт, а бред. То что там написано - чистой воды мазахизм. Потом через пол года, немного подзабыв эти стандарты будешь сидеть и тупить "что же это я(он) тут натворил блин..."

Так и скажи: «Не понимаю я еще, что там такое понаписано». А то мазахизм, бредятина… там никто не пропагандирует написание такого кода, просто тест на знание JavaScript ради спортивного интереса или just for fun.

мне вот интересно, скорее, показывает ли этот тест что-нибудь. Или это очередной писькомер?

Да ничего он не показывает, нормально можно программировать и без знания этих тонкостей, просто наступает момент, когда начинают интересовать такие вещи или, например, всякие страсти с [[call]], [[class]], Reference, Completion, как в статьях Дмитрия Сошникова. Мне раньше тоже хватало по уши программирования фреймворка, не до чтения спецификаций было)

Я такого не говорил. Ошибся в 6ти ответах. Как раз там где и написана туфта, которую и применять нигде не применяют.

Жестокий тест. В практике практически не применимо (извините за тавтологию). Нужно только для спортивного интереса.
С первого раза у меня вышло: You've got 4 answers wrong (#2, #3, #8, #9).
Со второго все поправил.

Не ответил на 5 (не заметил вызов функции) и на 14 (с чего-то решил, что переменной с именем undefined быть не может). Такие тесты, вообще говоря, скучны -- сидишь, компилятором работаешь.

По поводу применимости/неприменимости: в экзамене Zend на сертифицированного PHP-программиста много подобных вопросов (на знание PHP, разумеется), он тоже, скажете, туфта? :)

так а что такие тесты показывают?

Знание языка, очевидно, на котором пишешь. Мне щас трудно вспомнить конкретные примеры, но некоторые баги я бы исправлял в несколько раз дольше, если бы не знал многих тонкостей. Если бы вообще исправил. А уж выяснение, почему твой код не работает в сочетании со сторонним, это вообще песня.

8 из 14, стыд мне и позор. Два, причем, по невнимательности.

Спасибо, отличный тест, теперь я знаю, что еще нужно подтянуть.

Ну, знаете, в чистом виде это применять вряд ли можно. Но сам подходы реюзабельны еще как.

Представим себе конструкцию:

var myEngine = function(){
// инициализируем что-нибудь нужное
arguments.callee.myMethod = function(e){
// сделать что-нибудь полезное
}
}
myEngine.myMethod = function(){
myEngine(); // инициализация
myEngine.myMethod.apply(this, arguments); // к этому моменту myEngine.myMethod будет ссылаться уже на новую функцию
}

Т.е., в итоге получаем, что инициализация происходит неявно и один раз. Наверняка же такую же вещь можно сделать поизящнее :)

ну да... но насколько хорошо надо знать язык, чтобы успешно применять его на практике? Возьмем хотя бы этот тест

(function(){ // 1
    return typeof arguments;
})();

ну как бы да, надо знать, что arguments - не массив и добавить в него чего-то и отправить в следующую функцию так сходу не получиться. Но зачем знать его тип? Один раз пишем toArray и запоминаем, что arguments это вам не Array

var f = function g(){ return 23; }; // 2
typeof g();

(function(x){ // 3
    delete x;
    return x;
})(1);

var y = 1, x = y = typeof x; // 4
x;

да, полезно знать, что присваивание выполняется справа налево

(function f(f){ // 5
    return typeof f(); 
})(function(){ return 1; });

у параметров приоритет перед названием функции? Ну может иногда пригодиться

var foo = { // 6
    bar: function() { return this.baz; }, 
    baz: 1
};
(function(){ 
    return typeof arguments[0]();
})(foo.bar);

теряется контекст (своими словами)? Пишем один раз bind и запоминмаем, что контекст может теряться

var foo = { // 7
    bar: function(){ return this.baz; },
    baz: 1
}
typeof (f = foo.bar)();

var f = (function f(){ return "1"; }, function g(){ return 2; })(); // 8
typeof f;

var x = 1; // 9
if (function f(){}) {
    x += typeof f;
}
x;

да, полезно знать, как переменные в булевский тип преобразовываются и что происходит при конкатенации строки и числа

var x = [typeof x, typeof y][1]; // 10
typeof typeof x;

(function(foo){ // 11
    return typeof foo.bar;
})({ foo: { bar: 1 } });

это просто на внимательность

(function f(){ // 12
    function f(){ return 1; }
    return f();
    function f(){ return 2; }
})();

если в функции тонна вложенных функций, то это какбэ символизирует

function f(){ return f; } // 13
new f() instanceof f;

интересно, можно подменить возвращаемый объект... хотя пока не вижу применения

with (function(x, undefined){}) length; // 14

ну и еще полезно знать, что функция - тип данных, бывают функции-литералы и что возвращает typeof (из того, что нужно для прохождения этого теста)

кроме того, если не знаешь, как что-то работает, это ж легко можно проверить

итого, я насчитал где-то 4 практических вопроса. А вы?
---
про копание в чужом коде: в идеале нужно знать все про язык, потому что все, что ты не знаешь может быть использовано против тебя везде :) А если серьезно, то я затрудняюсь с более реальным списком для этого случая. Ничего в голову не приходит...

subzey, а можно это как-то поподробнее и с цветными картинками, а то я не уверен, что я правильно понимаю сказанное? (с)

> интересно, можно подменить возвращаемый объект... хотя пока не вижу применения
синглетон

убедили, 5 из 14 вопросов :)

Кстати о практическом применении #12. Недавно спрашивали, почему здесь ничего не работает:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
jQuery.noConflict();
function $() {}
$(); // $ is not a function
</script>

Без понимания того, что функция $ будет создана раньше, чем выполнится jQuery.noConflict, найти ошибку было бы сложно.

А это уже кстати ерунда. компилятор никогда не должен забегать на перед и создавать функции раньше их использования, в этом беда JS. Как сказал гозар у меня написано в подписи. А то что делает ECMA - пытается добавить интеллектуальности компилятору - его и губит.

Чушь.

Это не чушь, а сотни набитых шишек на голове опытных программистов. Попробуйте в С++ создать функцию позже ее ипользования...
Изза этого кстати, eval и медленный, т.к. компилятор сначала пытается найти такие вот функции, а потом все остальное.

Функции в C++ создаются на этапе компиляции, так что в любом случае до использования, не зависимо от места объявления.

Он в любом случае парсит весь скрипт сначала, eval тут не причем.

Да не вопрос, только прототип объявить.

Правильно. Это и есть обьявление функции, только без тела. тело подкрепляется потом. В обьявлении прототипа главное то, что нам уже есть куда ссылаться при компилации ее использования.

нет, он фактически проверяет, знаешь ли ты, можно ли "переопределить" функцию

ну я, думаю, объявление функций перед использованием ускоряет компиляцию. Это и было причиной такого правила. Вопрос в том, насколько далеко в прошлое PeaceCoder хочет вернуться ;)

Каким образом? Как парсился весь скрипт до выполнения, так и парсится.

Тест - просто спортивное состязание для себя, больше, конечно теоретический, но и на практике многое пригодится.

Здесь ещё дополнительные вопросы пишут: http://groups.google.ru/group/comp.l...170b5696?hl=en

Сюда тоже добавлю, пригодится знать:

1. Каков результат выражения 1..z:

a) SyntaxError
b) Новый object Range (эквивалентно new Range(1, "z")) включая цифры и буквы
c) undefined
d) Ошибка Range объекта (несовместимые типа для range: number и string)
e) ReferenceError "z" is not defined

2. Каков результат выражения 100['toString']['length']:

a) 100
b) 3
c) 1
d) SyntaxError
e) 8

Без вариантов ответа 1-й вопрос был бы легче :D

На то это и quiz, чтобы проверить внимательность, и насколько человек уверен в своих ответах, не собьют ли его с толку, "вроде как тоже правильные ответы" ;)

Ответил на оба вопроса?

Да. Ну 2-й вопрос после 14-го из теста легко было понять, а вот на 1-й сначала задумался…

Еще один (правда, уже обсуждался здесь):

function foo() {
  return this;
}
 
alert(foo === foo.prototype.constructor); // true
alert(foo() === foo.prototype.constructor()); // ?

a) true
b) false
c) зависит от реализации

http://perfectionkills.com/javascrip...#comment-58304

Да, первый запутывает. Только набирая alert(1..z) сообразил, что здесь на самом деле.

UPD: Вот такой интересный код найден на просторах интернета. Не знаю, на сколько он в тему, но мне показался интересным.

(x=[].reverse)() === window // true

Вопро� �: как так?

Это нормально. Метод reverse по завершении алгоритма выполняет return this, а т.к. мы сохранили ссылку на него в свойство x объекта window, то вызван по этой ссылке он будет в контексте window, и возвратит соответственно window.

Почти ;)

А здесь мы не сохранили в свойство объекта window, но, всё равно - результат window, почему?

var a = {
  x: null
};

(a.x = [].reverse)() === window; // true

Тоже, кстати, разбирался этот вопрос здесь.

Ещё один интересный с топика (немного изменил):

alert((function(){return 2*3;}).toString() === function () { return 6; }.toString());

a) true
b) false
c) зависит от реализации

а да… после операции присваивания мы получим ссылку на функцию. Тогда так:
Метод reverse по завершении алгоритма выполняет return this, а т.к. мы получим на него ссылку в результате операции присваивания, то вызван по этой ссылке он будет в контексте window, и возвратит соответственно window.

Сбило то, что ([].reverse)() сохраняет контекст

Вот этот вопрос: http://twitter.com/tobeytailor/status/8998006366