Pull to refresh

Comments 16

if data isnt off

Воу-воу-воу, меньше наворотов! Если они есть — это не значит, что надо применить все сразу :) «if data»

if @errors_list is undefined
    @errors_list = {}
if @errors_list[field] is undefined
    @errors_list[field] = []

Отличные оператор есть ||=
@errors_list ||= {}
@errors_list[field] ||= []

Кстати слово list тут лишнее, да еще и неправда, у вас хэш, а не список :)
В CoffeeScript есть такой способ:
@errors_list ?= {}
@errors_list[field] ?= []

Пишут, что it can <...> be used for safer conditional assignment than ||= provides, for cases where you may be handling numbers or strings.
И компилируется по-разному. Код
x = 0
x ||= 1

y = 0
y ?= 1

превращается в
var x, y;

x = 0;
x || (x = 1);

y = 0;
if (y == null) {
  y = 1;
}
Not bad! Хотя я не помню, честно говоря, когда использовал уже эту запись для создания чего-то другого кроме массивов и объектов.
В редакторе нет подсветки Coffee, использовал питоновскую.

На Ruby подсветку смените, лучше подходит.
Спасибо! Так действительно лучше.
Воу-воу-воу, меньше наворотов!

Временами хочется поэзии, чисто для разнообразия :)

Отличные оператор есть ||=

Упс, косяк. Спасибо!
По теме, сугубо из желания сделать мир лучше, субъективное мнение. Статью закончил читать с некоторым разочарованием. Сам по себе пример вполне жизненный, валидация — добро, и не только для форм :) Но исполнение не очень радует.

К статье:

Зачем двойной листинг с комментариями? Под кат бы его, он только сбивает с толку свои появлением второй раз, когда уже собрался читать дальше :) Да и когда тебе показывают комментарии в духе "# вернет true, если число больше заданного", невольно начинаешь чувствовать себе идиотом.

Тема классов не раскрыта совсем. Даже конструктора нет, не говоря про полиморфизм и т.д., в вашем примере никакой разницы не было бы, даже если все переписать на глобальные функции переменные. Вы даже после создания инстанса сразу уничтожаете класс :)

validation = new validation

По коду:

Чем вам так нравятся инверсные условия? Я лично в таким нагромождениях уже не могу с ходу их разобрать:
            unless result in [true,false]
            ...
            # если не просили пустую строку, но ничего не получили
            else unless 'required' not in rules and str.length is 0
                if result is no

Что, простите? О_о Это не конкурс головоломок, это же код. К слову, комментарий тут под стать коду и тоже ломает мозг(не просили, но не получили...?!). Мне лично кажется, что в этом условии даже есть ошибка. (Правило внесения отрицания под скобки: !(a && b) раскрывается как !a || !b)

Зачем ошибки отделены от класса в отдельный внешний объект? Это же часть логики класса, хранили бы их в статическом поле класса.

Почтой валидатор не пропустит мой ящик :) Объект класса назван с маленькой буквы, да и правильнее назвать «Validator» — вроде бы и мелочь, но неопрятно. Еще всякие мелочи бросаются в глаза. Нормальный прототип, но в продакшн в такой виде не пустил бы :)

Если вы хотите опубликовать цикл примеров — заведите репу на гитхабе, выложите их там рядом со всеми необходимым зависимостями и страничкой-примером, вам спасибо большое только скажут :)

Позвольте отчасти с вами не согласиться, коллега.

Перфекционизм с одной стороны, и сделать «чтобы работало» с другой стороны — оба экстремума плохи, так как чреваты повышенными потерями времени и сил. Есть масса срединных вариантов, один из них я как раз и показал. Предложенное решение хорошо тем, что оно написано менее, чем за полчаса, работает и, что немаловажно, правится и расширяется, в том числе методом перегрузки.

Конструктор — это возможность, а не необходимость. В данном случае применения ему я не вижу. Объект, кстати, не разрушается, но ключевые свойства инициируются при каждом вызове. Так надо.

Запутанный кусок, формулирующий логику, действительно формулирует запутанную логику. Эта логика именно такова — пустую строку можно ожидать, а можно и не ожидать, при этом она может быть, а может и не быть, и бизнес-логика приложения может подразумевать именно четыре варианта. Это случай из практики, мне будет сложно его объяснить тому, кто с этим не сталкивался.

Зачем двойной листинг с комментариями?


Некоторым читателям удобнее так, некоторым эдак. Проскроллить действительно несложно. А как сделать кат? Вы имеете в виду, чтобы сворачивалось?
Я просто к тому, что это решение на скорую руку — вполне подойдет для решения задачи здесь и сейчас, но вы все-таки статью пишете, которую другие люди будут читать. Мне кажется они заслуживают хорошего продуманого кода. По этой же причине я и говорю про нехватку ООП и OOAD. Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.

Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее:
if result in [true, false]
  if ('required' in rules || str.length > 0) && result == false
    ... # ловим ошибку
else
  .... # перепишем результат
они заслуживают хорошего продуманого кода


Именно это я и хотел показать. Фактически, есть единственный способ для того, чтобы обезопасить себя от перфекционизма — иметь часы перед глазами.

Какой смысл в суперразработчиках, если они тратят время и деньги своего работодателя на то, чтобы сделать суперкрасивый код, вместо того, чтобы добиться вполне утилитарных задач: сделать его быстро, и сделать его сопровождаемым?

('required' in rules || str.length > 0) && result == false


Это не Coffee.

Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.


Не уверен :)

Вообще, тут очень многие хорошие статьи не набирают должного количества плюсов. Вопрос в аудитории — лет пять назад она была принципиально другой. Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь.
Это не Coffee.

coffee> if ('required' in rules || str.length > 0) && result == false then true else false
false

O RLY? Но даже если бы был косяк в синтаксисе — вы игнорите главный тезис, что зачем-то навернули сложности.
Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь

Спасибо, да, запишу на свой счет, что я книжки не читаю и предпочитаю яркие простые картинки и алкоголь, раз вы так лихо про всех все знаете :)

Материал невысокого качества. Это не повод оправдываться «утилитарностью и воздержанием от перфексионизма» — не бойтесь, он вам не грозит. Что бы не тратить время — пишите хороший код сразу, что вам мешает :) Не можете — тренируйтесь! Как раз на тему книг — вам бы «Совершенный код» и «Рефакторинг. Улучшение существующего кода» прочитать. Они не привязаны к языкам и как крутятся вокруг тем хорошего/плохого/достаточно хорошего кода.
Читал. И далеко не только.

А вот на личности переходить, даже когда заканчиваются аргументы — не вежливо. И принимать все замечания на свой счет — тоже не разумно. ;)
По поводу дизайна — не самым лучшим решением преставляется описание правил в виде строки.

Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.

Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.

Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).

Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.

Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
Код с комментариями
Открывается и все показывает
не самым лучшим решением преставляется описание правил в виде строки...


Вот и вы тоже невнимательны. Решена конкретнейшая утилитарная задача, по условиям ТЗ: «портировать правила CodeIgniter с сервера на клиент». Там есть и соглашения о порядке следования правил. Зачем мне лезть со своим мнением в API, если целью является простое его использование?

А то, о чем вы подумали, многократно реализовано, например в jQuery Forms. И многие подумали также. Поэтому и минусы — просто непонимание вследствие невнимательности. Слишком много тезисов… :)

Скрывать текст можно тегом


Спасибо!
Sign up to leave a comment.

Articles