Совсем недавно я поделился постом, в котором собрал забавные комменты в исходном коде и читателям зашло. И я решил, а почему бы не сделать похожую подборку, только с кривым кодом? Кому интересно, добро пожаловать под кат.
Как и в предыдущий раз, вдохновился я на этот пост благодаря очень популярному вопросу на Quora, а именно: Какой самый абсурдный код вы когда-либо видели? (Ориг. What is the most absurd code you've ever seen?)
Вопрос размещен пару лет назад, но туда все продолжают прилетать ответы. Несколькими из них я и поделюсь ниже.
Ответ пользователя Prashant Asthana
“Психологическая атака во время интервью”
Девушка с опытом работы с хорошо известными сервисами разработки на MNC. Согласно резюме, она была «разработчиком Java» и «звездным исполнителем». Я попросил ее написать алгоритм сортировки, но она надолго с ним застряла.
Я: Что ж, это требует времени. Можете ли вы просто написать программу для поиска наибольшего числа в массиве, а не полную сортировку?
Она: Легко.
У нее заняло около 10 минут, чтобы написать вот это:
int largestNumber = 0;
for (int i = 0; i < array.length - 1; i++) {
largestNumber =
array[i] > array[i+1] ?
array[i] : array [i+1];
}
System.out.println(largestNumber);
Я был уверен, что это просто глупая ошибка.
Я: Можете, пожалуйста, протестировать, будет ли этот код работать согласно ожиданиям?
Прошло еще 5 минут.
Она: Да, все работает хорошо.
Я: Каков был входной набор?
Она: 1,2,3,4,5
Я (затаив дыхание): Просто сделайте реверс массива и проверьте еще раз.
Прошло еще 5 долгих минут.
Она: Ой, точно, глупая ошибка. Я сейчас все поправлю.
int largestNumber = 0;
for (int i = array.length - 1; i > 0; i--) {
largestNumber =
array[i] > array[i-1] ?
array[i] : array [i-1];
}
System.out.println(largestNumber);
Она: Теперь все работает отлично на 5,4,3,2,1. Я всё проверила.
Пытаясь отвлечься от этой продолжающейся психологической атаки…
Я: Так почему вы хотите сменить компанию?
Она: Я в поиске более сложной работы...
Ответ пользователя Thomas Breckinridge
Несколько десятков лет назад у нас на стажировке был ученик старшей школы, чью работу особо не проверяли. В конце концов, его код передали мне, чтобы определить, стоит ли его переписать или просто залить это все бензином и сжечь.
Проблема была в том, что пацан был настолько умен, что сделал все свои переменные зависимыми от регистра и длины сочетаний букв haht. По какой-то причине ему это нравилось. Например, hahthahthaht отличается от hahtHahthaht, и снова от hahthahthaHt и hahthAhthahT.
Я не потратил слишком много времени, чтобы решить, что тысячи строк кода, как
if (hahthAhthahT >= hahthahthaht ) then hahtHahthaht(hahtHahtHaht,HAhtHahthaht);
else
hahTHahthaht(hahtHahtHaht,HAhtHahthaht);
не стоят внимания и решил отправить всю эту хрень в bitbucket.
Небольшое обновление:
Изначально мне казалось, что это был код Borland Delphi/Object Pascal, пока в комментариях не указали, что Pascal нечувствителен к регистру, что абсолютно правильно. Это повышает вероятность того, что код был C ++ Builder, хотя возможно, что парень играл с невосприимчивостью к регистру, зависимостью от изменения идентификатора по длине и повторением строк haht. В то время мы широко использовали оба продукта Borland в большинстве наших проектов, VisualBasic, и Win32 API C / C ++. Тем не менее, этот код заставлял кровоточить глаза всех, кто его читал.
Ответ пользователя Alan Chavez
Какой-то идиот написал вот это на JavaScript:
var obj = "{\"firstname\":\"" + firstName + "\",
\"lastname\":\"" + lastName + "\"}";
var res = JSON.parse(obj);
return res;
Это довольно глупо, потому что он объединяет строки для построения JSON… В JavaScript!
Нет необходимости объединять строки для построения JSON в JavaScript. Нет причин вообще.
Этот фрагмент был доведен до моего сведения, когда программа начала ломаться, и идиот, который ее написал, продолжал говорить: «Эти странные символы портят программу».
Мне потребовалась 1 минута и 36 секунд, чтобы понять, что это кавычка в имени (O’Conelly), нарушающая код. Мне потребовалось 2 минуты, чтобы переписать код правильно.
Этот код был написан «VP of Engineering». Пару недель спустя его уволили.
Ответ пользователя Ross Dickey
Это просто безобидный пример из базы кода, но здесь есть ряд вещей, которые сводят меня с ума:
- Имя функции от первого лица («мы хотим» неявно, не делайте так)
- Имя функции с использованием CamelCase (это Python, а не C#)
- Комментарии, которые объясняют простые очевидные строки
- Использование хэша, где сработал бы if
- Или, если вам нужен хэш, сделайте его статическим и не переопределяйте его одинаково при каждом запуске функции
- 5 вечера указано в комментарии, где час> 16. Это сбивает с толку. Пропустите комментарий или используйте> = 17 в коде, чтобы числа совпадали
- Числа, передаваемые в виде строк
- Отрицательный ноль (?!?)
- Табы. Это Python, а не C++. Используйте пробелы.
Может, я что-то упустил?
Ответ пользователя Yoseph Radding
Ох, ребят. Я работаю с человеком, который не должен быть разработчиком. Совсем. Он имеет 10-летний опыт работы и пишет код хуже, чем junior разработчик. Самый абсурдный код, который я когда-либо видел, это его код.
Вот, что стало последней каплей:
function foo(a) {
if (a) {
return transform(a);
}
return transform(a);
}
Ага. Он написал функцию, которая проверяет некоторые условия и выполняет некоторые действия. И если это условие не выполняется… оно выполняет то же самое чертово действие.
Этот кусок кода он писал с множеством изменений, которые при этом были еще и запутанными. Ему понадобилось 3 дня, чтобы написать весь код и решить простейшую задачу.
Мне потребовался 1 день, чтобы зайти и исправить его код и заставить его работать должным образом.
Ответ пользователя Ryan Lam
#!/usr/bin/sh
# Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T
# All Rights Reserved
# THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T
# The copyright notice above does not evidence any
# actual or intended publication of such source code.
#ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */
Это исходный код программы / bin / true в какой-то UNIX-системе, созданной AT&T. Для непосвященных true — это обычная команда оболочки, которая по сути ничего не делает и возвращает успешный результат. (Это полезно в контексте бесконечных циклов, например, while true и т.д.) Такое поведение может быть легко достигнуто с помощью пустого сценария оболочки с “нулевыми” командами.
Может показаться, что в ходе консультаций с мудрыми юристами AT&T, кто-то решил, что им необходимо защищать авторские права на содержимое / bin / true для AT&T UNIX. Поэтому они вставили шаблонное уведомление об авторских правах в пустой сценарий оболочки, который ничего не делает, и в процессе фактически заявили об авторском праве на пустой файл с абсолютно нулевыми инструкциями.
Поэтому в следующий раз, когда вы напишите пустой сценарий оболочки без кода, обязательно проконсультируйтесь с юристом. Вы можете нарушать авторские права AT&T на…ничего.
Ответ пользователя Khaled Bakhit
rows= SELECT * FROM users
int count= 0
for each row in rows
count= count + 1
return count
Ответ API занимал целую вечность.
Что делало приведенный выше код еще хуже (помимо использования простой статической функции), select запрос вызывал бы все доступные столбцы. При условии, что мы имеем дело с очень большой таблицей, у системы просто не хватило бы памяти и она бы сломалась.
Но подождите, это не так!
Я посмотрел развернутый фрагмент от того же самого разработчика на куске кода, который он написал год спустя (и как ему только удалось продержаться так долго, не понятно). На этот раз он узнал о функции Count, но совершенно неправильно использовал ее.
rows= SELECT * FROM users
int count= 0
for each row in rows
count = count + 1
checkCount= SELECT count(*) FROM users
if count != checkCount
throw Error
return count
Этот фрагмент кода часто вызывал исключения, потому как к моменту выполнения первого счетчика, таблица заполнялась бOльшим количеством записей, предоставляя второму счетчику другое значение…
Правдивая история. Хотел бы я, чтобы это было не так.
Заключение
Почитать больше ответов в оригинале можно здесь. Ну и по традиции, делитесь своими вариантами абсурдного/глупого/странного кода, который вы встречали в вашей практике. Думаю, почитать будет интересно не только мне, но и всем, кто наткнется на эту статью :)