Битва с «китайским кодом»: строка или число?
Меня давно поражает, как мои юные коллеги умудряются выпекать с бешеной скоростью бездну кода, притом выполняющего свою задачу, как часы,- но стратегически совершенно непродуманного, безобразного и безграмотного, тёмного, как критский диск, и хрупкого, как карточный домик, прямо-таки как целая карточная Вавилонская башня. Поддерживать его, а тем паче модифицировать - мука мученическая, требующая в высшей степени подозрительных начальству расходов времени и никем не учитываемых расходов нервной и моральной энергии.
Сегодня наткнулся на очередную подлянку и чёрт меня за язык дёрнул, не смог промолчать. Когда-то моему предшественнику потребовалось изготовить из двух не уникальных кодов один уникальный идентификатор. Не мудрствуя лукаво, он эти коды конкатенировал (вульгарно выражаясь, склеил), ну а я, конечно, дорабатывая полгода спустя тот же модуль, заметил, что это уникальности отнюдь не гарантирует. От проект-менеджера последовало указание вставить между кодами «тире», то есть дефисоминус. Меня мучили смутные подозрения, когда я это делал (привет от китайского кодинга - в дюжине мест) и не зря.
Как по вашему, какого типа будет результат строчной склейки двух переменных, пусть сами они исходно и представляли собой целые числа? Разумеется, строчного. И в базе соответствующее поле действительно имеет строчный тип. Но и клиентский и серверный код в неисчислимых местах предполагает, что имеет дело с числовой величиной! Валидирует как число, санитизирует (преобразует) к числовому типу во избежание SQL-инъекций, пихает в JSON и SQL-запрос без кавычек. Естественно, после вставки дефисоминуса стали всплывать самые разные косяки и что самое ужасное - невозможно предсказать, где они ещё всплывут; это может разве что автор кода предположить по памяти.
А где автор кода? Думаете, его уволили? Ушёл на более перспективную работу, кажется, даже в Москве.