Комментарии 22
Забавно - была такая же ошибка в проде у нас несколько лет назад. Очень тогда удивился что есть week year. В итоге сделал check style правило что нельзя писать YYYY, что бы никто больше не использовал.
Отличная статья, и заголовок тоже! Выглядит, правда, знакомо:
Круто! Рад, что реализовали мое предложение (не понял правда, на что пеняли в орфографии, вроде все в порядке...)
new Date("2024/12/31");
По привычке глаз дёргается когда подставляется дата текстом в класс с полной уверенностью, что она там сама разберётся где что.
В некоторых случаях , в зависимости от локали или поведения пользователя (пользователь например из США) - дни и месяцы могут быть спутаны местами, и при этом проходить валидацию, например: 2024/12/11 - и вот сиди гадай - это 11 декабря, или 12 ноября? А как код это примет распознает? А точно ли мы дату проверяем на входе, а не просто просим пользователя ввести циферки? А точно ли сервер правильно локаль выставил, чтобы автоматически порядок yyyy mm dd понимал?)
Когда отойдете от точечных диагностик, реализация которых обходится вам в 10-30 строк кода ? На них далеко не уедите
Когда уже двинетесь в сторону spring, на котором все сидят ?
За последнее время у нас вышло большое количество диагностик достаточно сложных по реализации. Для большинства из них нужно было внести весомое количество правок и расширений в наш data-flow механизм, что представляет из себя на порядок больше, чем 10-30 строк кода.
В случае со Spring мы сами за. В будущем Spring специализированные диагностики мы обязательно добавим
Кстати, у меня крепко-накрепко засела мысль, что у вас датафлоу сидит на С++(давно было не помню, то ли в ранних статьях, то ли на конференциях/кулуарах узнал)
Какой плюс от этого был еще, кроме быстрого запуска анализатора, который на старте что-то умеет? А потом стагнация на 5 лет - вроде ничего такого вы не публиковали и не "хвастались" (
Только диагностики, которые охватывают дай бог скоуп всего класса
Когда планируете ударными силами джавовый кор развивать? Может на первых порах будет затишье с вашей стороны, но потом можно навернео сказать про вас "Русские долго запрягают, но быстро едут" :D
Ведь проще развивать и искать людей на развитие всего этого
С с++ кором экспертизы на человека одного должно быть сильно больше либо задействование профильных коллег,
Отсюда наверное и весомое количество правок и расширений пришлось накрутить и много времени потратить пришлось ИМХО
Плюсы нашего DataFlow заканчиваются на языке, на котором он написан (простите, не удержался :))
Тогда казалось что неплохо переиспользовать уже готовый код, но по итогу это действительно проблематично поддерживать именно в таком виде. Поэтому и по сумме других накопившихся проблем активное развитие на некоторое время притихло.
Зато теперь оно идёт ударными темпами и, надеюсь, уже совсем-совсем скоро покажем расскажем о новых технологиях, реализованых на Java. Можно сказать, что весь этот год как раз "запрягали" :) - всё же надо не только ядро прокачивать, но и над самим анализатором работать.
А еще стремно, что запуская Java анализатор под капотом еще и подгружается c++ библиотека =)
У многих настроена "безопасность" все дела, и чтобы скачать потыкать посмотреть рассказать банально может не получиться тк "безопасность" это не даст. Нужно будет пройти некоторый путь чтобы это все же сделать, легче махнуть рукой: "штош я попытался"
И какой вывод? Помимо необходимости покупки PVS-Studio, конечно.
Я бы сделал такой. Авторы форматтеров соблазнились на краткую запись (dd, MM и т.д.), чтобы форматирующие строки выглядели наглядно. Но когда потребовалось ввести дополнительный функционал (week year) в рамках той же концепции повышения наглядности, это на самом деле привело к закладыванию чудовищной мины. А вот если бы они не гонялись за наглядностью, и использовали что-то типа {year} и {weekyear} (или, как вариант, {year} и {year:week}), проблемы бы не возникло никогда. Обобщить в виде правила довольно трудно, но на уровне интуиции это весьма знакомая ситуация. «Если сделать так, код/формула/DSL/выражение будет выглядеть почти как запись на человеческом языке». — «…Но при этом пострадает универсальность, поэтому лучше воздержаться!».
И какой вывод?
Баги будут всегда, на работу лучше приходить выспавшимся, javadoc стоит читать, но и это не даст стопроцентной гарантии.
А вот если бы они не гонялись за наглядностью, и использовали что-то типа {year} и {weekyear} (или, как вариант, {year} и {year:week}), проблемы бы не возникло никогда.
Те же баги, вид сбоку.
Или вы никогда не печатали совершенно другое слово вместо нужного?
Кто-то внезапно заржёт в опенспейсе, жена сковородку на кухне уронит или в наушниках начнётся любимая песня, отвлёкся и — привет.
Баг возник не из-за лаконичности, а из-за выбранного символа. Если бы вместо Y для week year выбрали какой-нибудь Q, то ошибиться было бы сложнее.
Если выбрать Q, пропадает весь смысл в схеме форматирования, когда форматирующая строка понятна без чтения документации. Зато появляется риск, что Q встретится где-нибудь в обрамлении и будет интерпретирована как элемент форматирования. У китайцев, например, часто встречается QQ, что, насколько я понимаю, соответствовало бы двухзначной записи недельного года. То есть, Q это худшее из обоих подходов. И небезопасно, и не наглядно.
Сделать и безопасно, и наглядно в данном случае невозможно, и стоило бы сосредоточиться на безопасности, например, использовав схему {type:flags} или любую аналогичную.
Баги будут всегда
Это не оправдание, чтобы не думать, откуда взялась ошибка в каждом конкретном случае, и как предотвратить этот тип ошибок в будущем.
форматирующая строка понятна без чтения документации.
Мы с вами общаемся в комментариях к статье, которая показывает, что эта точка зрения — опасное заблуждение, ведущее к трудноуловимым багам.
Авторы приведённых фрагментов кода тоже, вероятно, думали «год — это четыре игрека, смысла открывать JavaDoc нет». И code review этот код мог пройти примерно по таким же соображениям. Но, как оказалось, есть нюанс.
Вот фрагмент таблицы из JavaDoc к SimpleDateFormat:
| Letter | Date or Time Component |
|------- + -----------------------|
| H | Hour in day (0-23) |
| k | Hour in day (1-24) |
| K | Hour in am/pm (0-11) |
| h | Hour in am/pm (1-12) |
Вам действительно понятно без чтения документации что это за K, k такие и что они означают?
Не читаешь документацию ≡ стреляешь себе в ногу.
Зато появляется риск, что Q встретится где-нибудь в обрамлении и будет интерпретирована как элемент форматирования.
Только если не читать JavaDoc.
SimpleDateFormat в Java 21 в качестве специальных символов используется 15 латинских букв из 26. Это если не учитывать регистр. Обрамление должно быть заключено в одинарные кавычки, иначе жизнь разработчика будет полна сюрпризов.
То есть, Q это худшее из обоих подходов. И небезопасно, и не наглядно.
Наткнувшись во время code review на Q ревьювер задался бы вопросом «что это вообще за хрень?» и полез в JavaDoc, тем самым эту безопасность повысив.
Сделать и безопасно, и наглядно в данном случае невозможно, и стоило бы сосредоточиться на безопасности, например, использовав схему {type:flags} или любую аналогичную.
Чем длиннее ключевые слова, тем выше вероятность использования метода «Copy-Paste» без критического осмысления.
Это не оправдание, чтобы не думать, откуда взялась ошибка в каждом конкретном случае, и как предотвратить этот тип ошибок в будущем.
Ошибка могла взяться от невнимательности, из-за использования бредогенератора на основе языковой модели, из копипасты с StackOverflow. Из-за лени открыть JavaDoc, наконец.
Предотвратить в общем случае никак, кроме дисциплины. Некоторые люди ничтоже сумняшеся коммитят код, который в IntelliJ IDEA чуть более чем полностью залит жёлтой краской и им не стыдно.
Ну и что вы им сделаете?
Я не знал, что они добавили K (я редко пишу на Java), но это значит, что они как раз и совершили ту самую ошибку с гипотетической Q: взяли худшее из обоих миров. С чем я их и поздравляю.
А чтобы люди читали документацию, их не надо было соблазнять dd и MM.
Вообще, не очень понимаю, о чём спор, если мы видим ситуацию примерно одинаково.
Интереса ради - а это безусловно выдаваемое замечание, или есть какие-то случаи (эвристические или явно указанные), когда YYYY в формате даты считается корректным?
Кодеру, который взял чужой проект, сделать глобальный поиск в коде: найти YYYY и попытаться разобраться зачем это там.
YYYY? yyyy!