JavaScript
Abnormal programming
Comments 46
+37

Кажется, это одна из библиотек серии «Счастливой отладки, суки!» :-D

+5

Очень неплохо! Правда есть и недостатки, например имена лексических переменных с очепятками никак не перехватываются, да и синтактические ошибки по-прежнему актуальны. Так что нужно сделать babel-плагин, который будет выполнять пред-обработку и учитывать опечатки во всех сущностях.

+8
Когда в следующий раз забуду принять свои таблетки, обязательно напишу такой плагин. Правда, все ошибки перехватить всё равно не удастся — допустим, если функция создаётся через new Function(), а имена переменных и тело функции конструируются в рантайме.

Вообще, кстати, мне всегда было интересно, почему в JS нельзя получить напрямую доступ к контексту выполнения и посмотреть, допустим, список всех переменных в этом контексте.
+4
почему в JS нельзя получить напрямую доступ к контексту выполнения

Раньше можно было даже программно доступ получить через parent, потом убрали видимо из соображений чистого кода и безопасности/sandboxing-а. Можно почитать тут подробнее: http://whereswalden.com/2010/05/07/spidermonkey-change-du-jour-the-special-__parent__-property-has-been-removed/


Сейчас доступ только из отладчика по скрытому свойству [[Scope]]. Подозреваю, что для node.js можно и сейчас получить доступ через V8 natives: https://www.npmjs.com/package/v8-natives, только надо с флажком будет запускать процесс


Правда, все ошибки перехватить всё равно не удастся

Если перехватить сами вызовы, которые могут генерировать новый код динамически тем или иным образом, начиная от new Function и заканчивая манипуляциями с DOM Node и создания новых script-секций, то вполне возможно
Подобная техника, правда не для шутки, а функционального тестирования, применяется в TestCafe: https://github.com/DevExpress/testcafe-hammerhead

+1
Наверное это можно устроить для JavaScript VM доступной для фикса, rhino (Java) или narcissus (javascript). Там можно служебные функции подёргать.

+1

Лучше не babel плагина, а eslint. Вообще есть плагина для eslint который проверяет существование модулей и файлов которые подключаются, но вот если бы был плагин который исправляет ошибки при запуске eslint --fix, было бы куда удобнее.

0

Теоретически можно заимплементить плагин для prettier-а, но это решает очень узкую задачу — выявление опечаток в именах подключаемых модулей, заданных в виде строковых констант. А если require(vasya${petya}) ?


Многие остальные вещи становятся известными только в runtime-фазе, так что ни EsLint, ни Flow тут не помощники. Поэтому если уж заморачиваться, то нужна более тяжелая артиллерия.


И еще раз важная заметочка: подобная задача вполне имеет место в динамическом анализе кода и функциональном тестировании. Есть как минимум:



Задачи ооочень нетривиальные в общем случае. К примеру, довольно проблемно перехватить сгенерированный script-блок из DOM-манипуляций, чтобы выполнить предварительную обертку.

0
Зачем запоминать, когда можно просто копировать и вставить? А страницу в закладки.
+8

В Руби есть gem "did_you_mean", который даже идет в стандартной поставке языка. Он тоже детектит опечатки, находит подходящий класс, метод, переменную или модуль, который скорее всего имел в виду автор, и падает с ошибкой, показыая правильное написание. Автор видит, что ошибся, исправляет ошибку, и код остается нормальным. С одной стороны, да, приходится опечатки исправлять, а с другой — все ж лучше получить нормальное сообщение об ошибке, а не "undefined is not a function".


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

+4
Те, кому не нравятся опечатки, а нравится, как бонус, автокомплит, пользуются typescript. И вывод и проверка типов там везде, а не только в названии внешних модулей.
0
В graphql тоже такое есть, по крайней мере, в сервере от apollo для nodejs
+1
Будет удобнее, если допилить какой-нибудь *lint плагин, чтобы если пакет не найден показать ошибку с названием возможного пакета. Тогда это будет круче и можно в разработке пользоваться без злых взглядов со стороны.
+10
втор сапсибо бoльшео, а бблитека бдет работат с CofeScript?
+2
Ну здорово. Но лучше было бы наверное Babel плагин написать, который конвертил бы код с очепятками в код без опечаток
+8
По хорошему такой плагин должен находиться между стулом и монитором компьютера на котором пишеться этот самый код.
0
«ться»

вообще, подобное может делать и IDE. Что, кстати, IDEA и ее производные делают: спорные места выделяются шрифтом.
+1
Есть гораздо более простое и тривиальное решение. Писать на любом языке со статической строгой типизацией.
+4
Ээээ… и что это изменит? Не в типизации ведь дело. Я вам и в c++ могу опечаток наделать, и в java, и точно так же упадёт. В чём разница?
+4

Разница в том что в одном случае упадет рантайме а во втором при компиляции)

0

Разница в том что оно не упадёт. Оно не скомпилируется. Я не пишу именно на C++, но во многих языках компилятор просто не допустит ошибок типа undefined is not a function / cannot read property of undefined. То же самое касается и не только полей структур / классов но и использования модулей, которые подгружаются не динамически а во время компиляции

0

Одно из самых распространенных заблуждений состоит в том, что статическая типазация, или новомодные обертки для ее эмуляции в виде ES-Flow, могут помочь побороть ошибку undefined is not a function, но на деле это невозможно сделать в статическом анализе.


Аналогичный примерчик на C#. В общем-то проблема в Nullable объектах, а не то, что часто принято приводить в качестве аргумента


// One
MyClass obj = null;
obj.someMethod();

// Two
delegate void SomeFunc(int x);
SomeFunc dlg = cond ? obj.someMethod : null
dlg(10);
0

В TypeScript есть возможность строгой проверки на null, которая такую вот ерунду исключает. Так что я бы осторожнее делал заявления вида "но на деле это невозможно сделать в статическом анализе"

0

Да, наверное можно получше сформулировать. Форма и значения в том или ином объекте могут стать известны только в runtime-фазе, например, когда прочли request body в HTTP-запросе и инстанцировали из него объект посредством JSON.parse — по сути преобразование из произвольного string в произвольный plain object.


Каждое из полей может быть null, undefined или чем угодно, но эта станет известно только в фазе выполнения. Есть такая штука как tcomb — это да, может помочь.


Опять-таки самая ближайшая аналогия из строго-типизированного языка, C#, это по типу:


dynamic excel = Interop.create("Excel.Workbook");
dynamic book = excel.Workbook[0];
book.Activate();
+4

Хотелось бы в будущем увидеть "истории успеха" о пропихивании этой библиотеки кому-нить в продакшн.

-1

Мне кажется, вы не в том направлении пошли. Про табличку сарказм помню, но намного полезнее был бы плагин для ide для исправления опечаток.

+4
Когда-то давно слышал о вирусе, который на 1 апреля находит на компе исходники и оставляет там кучу опечаток. Ура, теперь нам и это не страшно!
0
был бы хороший вариант с экспортом найденных опечаток.
что бы легко было после девелопмента в продакшен переводить.
0
Тут в комментариях уже несколько раз высказывали идеи обратить мою фантазию в полезное русло) Но честно говоря, я не очень вижу, чем экспорт опечаток мог бы помочь. Если опечатка критична, «голый» джаваскрипт в этом месте упадёт с ошибкой, по тексту которой вполне понятно будет, что произошло. А если ошибки нет — так, может, так оно и было задуман? В JS объекты часто используются как хеш-таблицы, обращение к несуществующему свойству в таком случае — штатная ситуация.
-1
Если опечатка критична, «голый» джаваскрипт в этом месте упадёт с ошибкой

Вопрос в том, когда он упадет в этом месте. Например, через две недели на продакшене.
+2
Ну так моя либа не занимается статическим анализом, и сообщение об опечатке может выдать лишь в тот самый момент, когда всё упало бы без неё.
-3
Такой модуль делает код не то что двояким, а вообще непонятно каким. Используйте иде и импорты, не занимайтесь анонизмом
0

Стоп! Товарищ автор, а что мешает тебе сделать линтер или какой нить компилятор, который будет ошибки исправлять прямо в коде в процессе написания? Ведь если ты делаешь это в тихую, просто по сути алиасы добавляя, почему бы не сделать это громко? я б не отказался иногда от такого иструмента. Шорткат какой и перепутанные буквы встали на место или проверка при потере фокуса. И тогда твоя шутка реально станет полезной. Да и думаю многие IDE будут не против такого механизма автоисправления кода

+1
Уже отвечал выше, но мне, в общем-то, нетрудно повторить)

Дело в том, что либа работает в рантайме, а для линтера или плагина к IDE требуется статический анализ. Статический анализ JS-кода — это задача не то чтобы совсем уж невозможная, но принципиально отличающаяся от того, что делает reqyire.js.
0

Нет, я понимаю, что ты делаешь в этой либе. И прекрасно понимаю, что одним AST тут не обойтись. Но на самом деле я как говорил о том, чтобы использовать твой движок нечеткого поиска дабы именно на основе рантайма генерировать правильный код. К тому же ты можешь, как самый простой вариант, сыпать варнингами в консоль о том что ты заменил, где и на что. ввести глобальный реквайр твоей либы, которая бы обернула обычный, и в девелопмент окружении сыпал матюгами на криворукого и слепого разраба за подмены, а в продакшене — ни подмены, ни варнингов. Упало — сам дурак, поднимай девелопмент и смотри в консоль. В общем идей море, главное время и желание. Тогда твоя разработка перейдет из разряда "сжечь еретика" в полезный инструмент разработчика

0
То есть вы хотите, чтобы в рантайме вместо «Error: cannot find module X» выдавалось «Error: cannot find module X, did you mean Y?» Это да, это можно организовать. Мне только полезность этого мероприятия представляется сомнительной. Самое сложное в правке опечаток — это найти опечатки. Понять, на что их нужно исправить, обычно тривиально.
0

Ну почти. Подменить, сообщить о подмене, указать где исправить. профит следующий:
1) человек знает где накосячил и может это исправить.
2) при этом он сразу видит результат своего труда, а не ошибок. допустим он реализует или проверяет некий сложный прототип в действии. так он сможет посмотреть верным ли он путем пошел и исправит опечатки на этапе рефакторинга, например.
Мне кажется, что в таком случае у программиста будет выше настроение и больше продуктивность. И вам по фану и людям радость

-1
Ругливые компиляторы и инерпритаторы от того и придумали, чтоб выполнялся тот код, который программист хочет, а не тот, который какой-то другой код, пытается отгадать.
Мне тоже не нравится «undefined is not a function», но эту ошибку можно увидеть только потому что js и так слишком добрый. Именно от этого его сложно дебажить.
Строго типизированный язык скажет кто не фанкшин и где не фанкшин. И, если ты очепятался, то он тебе об этом скажет, а не попробует отгадать твои мысли через кривые пальцы.
Only logged in users are able to leave comments. , please.