Зависит от того, что с этим кодом планируется делать в дальнейшем.
Если это разовая работа вида "сдал и забыл", исходники которой которую никому не предполагается смотреть, то можно оставить как есть и не париться. Всё и так работает, а интерпретатору всё равно, насколько понятно написан данный код.
Однако, как писал Мартин Фаулер, "хороший программист пишет код, понятный человеку". Рано или поздно возникнет необходимость этот код читать. За примерами далеко ходить не надо: обсуждая данный вопрос, мы
уже столкнулись с такой необходимостью, а в будущем возможны доработки либо изменения (исправления багов). Следовательно, хороший код должен быть написан понятно, причём понятно для всех, а не только для его автора. Судя по отсутствию каких-либо ответов и комментариев вот уже больше суток, данный код этому критерию не соответствует — никто просто не хочет выполнять бессмысленную работу, разбираясь с длинным запутанным листингом.
Но что значит "понятно"? Кому понятно? Но что такое вообще "хорошо написанный код"? Как узнать, что с данным конкретным кодом что-то не так, и главное, как это исправить? На эту тему было написано множество книг, многие из которых стали классикой разработки: Р. Мартин, Г. Ларман, М. Фаулер, "банда четырёх" и прочие. Это целая наука, на одно знакомство с которой может потребоваться не один год; нет никакой возможности уместить всё в один ответ из нескольких абзацев.
Вдвойне сложно обсуждать это на данном конкретном примере — к сожалению, он сделан в том стиле, в котором веб-разработка находилась примерно лет двадцать назад. Тогда сложных веб-приложений было мало, и в общем-то являлось нормой смешивать логику и представление в одном файле, в итоге превращая его в спагетти из html, php и javascript. От такой практики отошли, разделяя представление (разметку) и поведение (код на php) и вынося клиентские скрипты, где затем их можно было декомпозировать на отдельные переиспользуемые элементы.
Но завершать ответ в духе "код плохой, как поправить не скажу, и вообще это всё сложно" тоже не хотелось бы, иначе что это за ответ. Да и "наука" это конечно хорошо, но надо же с чего-то начинать, и начинать надо с чего-то конкретного. Поэтому попробую дать пару советов, которые может быть позволят делать код чуть лучше.
Сначала думать, потом писать. Попробуйте перед написанием кода подумать о структуре того, что собираетесь написать. Чем раньше вы начнёте задумываться о проектировании, тем лучше будут ваши перспективы как разработчика. Ещё до написания первой строчки кода опишите словами (на человеческом языке) элементы, из которых состоит желаемая функциональность, затем их дочерние элементы, затем дочерние дочерних — и на каком-то этапе окажется, что какие-то из них повторяются, а значит, являются первыми кандидатами на переиспользование. В системном анализе это называется "декомпозиция предметной области", на пальцах оно хорошо показано вот в
этом видео.
Думать о людях. В современных реалиях программисты работают в команде, поэтому делать код максимально читаемым для других людей давно стало стандартом в профессиональной области. Для этого придуманы "лишние" на первый взгляд вещи, такие как комментарии, длинные названия методов и классов, соглашения о стиле, стремление к единообразию, и т.д., и т.п. Даже если вы — единственный разработчик на проекте, по прошествии определённого времени вы можете выпасть из контекста, забыть что-то, и в результате придётся разбираться со своим кодом, так же как с чужим. Добавление комментария к функции с кратким описанием того, что она должна делать, поможет читателю понять намерение за кодом и, как следствие, лучше разобраться с реализацией.
Думать о будущем. Чтобы оценить качество написанного кода, проверьте его на так называемую "устойчивость к изменениям". Представьте, что у вас возникла необходимость что-то добавить в уже существующее поведение, причём добавлять будете не вы, а другой программист, который видит ваш код впервые в жизни. Насколько легко ему будет это сделать?
В лучшем случае для добавления функциональности нужно добавить какой-то элемент (например, класс). При этом старый (протестированный и рабочий) код не меняется, а значит, не возникает риска появления новых багов. Такой подход называется расширяемостью.
Несколько хуже, если нужно
изменение, т.е. правка старого кода. После такой правки работавший ранее код потребуется перетестировать. В общем и целом это всё ещё нормально — главное, код должен быть написан так, чтобы даже стороннему разработчику было понятно, где и какую правку нужно внести.
Плохо, если изменения потребуются в нескольких местах. И совсем никуда не годится, если эти места никак не связаны друг с другом, или связаны как-то неочевидно. В этом случае исправление выльется в череду бесконечных проб и ошибок (поправил в одном месте — отвалилось в другом — подебажил — поправил в другом — всё равно не работает — опять подебаджил — оказалось что проблема вообще не там — не смог найти, где проблема — откатил и т.д.). Такой код считается "плохим", потому что он создаёт лишнюю работу, а значит, неоправданно повышает расходы на разработку. В современных реалиях подобного подхода к разработке стараются избегать.
