Как сократить условия php?

Question

[Darth Moul]

Здравствуйте, можно ли сократить это множество условий? Если можно примерчик, я пока только изучаю php

if($_GET['year'] == '2016') {
	$jndns['year'] = '2016';
}
if($_GET['year'] == '2017') {
	$jndns['year'] = '2017';
}
if($_GET['year'] == '2018') {
	$jndns['year'] = '2018';
}
if($_GET['year'] == '2019') {
	$jndns['year'] = '2019';
}
if($_GET['year'] == '2020') {
	$jndns['year'] = '2020';
}
if($_GET['year'] == '2021') {
	$jndns['year'] = '2021';
}
if($_GET['year'] == '2022') {
	$jndns['year'] = '2022';
}
if($_GET['year'] == '2023') {
	$jndns['year'] = '2023';
}
if($_GET['year'] == '2024') {
	$jndns['year'] = '2024';
}
if($_GET['year'] == '2025') {
	$jndns['year'] = '2025';
}

Comments

[Tendor]

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

[FanatPHP]

интересно, что из двух ответивших so far, пока никто не проходил в школе сравнение больше/меньше - только эквивалентность.

[Gennady S]

Потому что нет задачи, заранее неизвестно, каким будет набор дат, будут ли это всегда численные значения. Вопрос в том, как сократить набор условий.

Answer 1

[Gennady S]

В цикле:

foreach (range(2016, 2025) as $year)
  if (intval($_GET['year']) == $year)
    $jdns['year'] = (string) $year;

Или без цикла:

if (in_array(intval($_GET['year']), range(2016, 2025)))
  $jdns['year'] = (string) intval($_GET['year']);

PS FanatPHP верно отмечает, если даты лежат последовательно в заданном диапазоне, проще сравнить условием больше-меньше:

if (intval($_GET['year']) >= 2016 && intval($_GET['year']) <= 2025)
  $jdns['year'] = (string) intval($_GET['year']);

Comments

[FanatPHP]

$_GET['year'] = '2016 поросят';

[Gennady S]

FanatPHP, именно.

[FanatPHP]

что "именно"?
ты тест завалил. переписывай :)

[Gennady S]

FanatPHP, не фантазируйте, по выходу из условия значение будет проверено, поскольку приводится к числу.

[FanatPHP]

Вот-вот, как раз о фантазиях и речь.
Пока у тебя ещё плохо с пониманием синтаксиса РНР, тебе надо не фантазировать, а проверять свой код исполнением.
Я тебе даже подсказал, дал пример входных данных, на которых твоя проверка скажет "ой, извинити дяденьки".
Приступай

[Gennady S]

FanatPHP,

php -r "echo (int) in_array(intval('2016 творцов кумира из PHP'), range(2016, 2025));"
php -r "echo (int) in_array(intval('2016                      '), range(2016, 2025));"
php -r "echo (int) in_array(intval('Я фанатею от PHP с 2016-го'), range(2016, 2025));"

[FanatPHP]

а какое отношение, я извиняюсь, все эти красивые слова имеют к тому коду, который ты накалякал в ответе?

[Gennady S]

FanatPHP, ну неточность допустил только в 3-м варианте, дописал в спешке по Вашему замечанию. В остальном, если intval пропустит число, то результат верный.

[Gennady S]

FanatPHP, поправил — (str) intval($_GET['year'])

[FanatPHP]

поправил ты только в одном варианте а в остальных так и осталось абсолютно бессмысленное (и к тому же ещё неправильно написанное) "(str)"
я ведь тебе не просто так говорю запускать свой код. это очень важное умение для прграммиста - не только ваять эпохальные творения, но еще и проверять, как они работают

[necrodeflorator]

Никогда не понимал этого вот бездумного intval. Если скрипт ожидает в параметре инт, а получает хрень, но почему-то продолжает работать как ни в чем не бывало - это плохой скрипт

[Gennady S]

FanatPHP, а, да, не str, поправил, это опечатка, т.к. работаю на 5-6 языках в стеке и все реже с PHP. Спасибо за замечание. Я так понял, человеку нужна строка, но это непринципиально в данном случае.

necrodeflorator, в GET может прийти все что угодно, валидация — это отдельная задача, в любом случае, во многих ситуациях достаточно привести к целому. В данном случае, задачи вообще никакой не стоит. Просто замена сравнения строк с примером. Если бы человек попросил упростить:

if($_GET['bla-bla'] == 'PHP') {
  $jndns['bla-bla'] = 'Logic';
}
if($_GET['bla-bla'] == 'Hello') {
  $jndns['bla-bla'] = 'World';
}

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

[FanatPHP]

Он тебе и говорит, что intval - это валидация для бедных. а по-хорошему скрипт вообще не должен обрабатывать невалидный запрос

[Gennady S]

FanatPHP, какой скрипт, по-хорошему? И что значит, по-хорошему?

Будет полной дурью, если пишете микросервис — делать проверки через прослойки, вместо прямого и простого сведения типа. Если повышать уровень до масштабируемых приложений, то тут в мире PHP не слишком много хороших решений. Я бы писал слой моделей с автоматизацией, для перехвата запроса через промежуточный уровень, чтобы до момента действия не дошло, если данные неверны. Ну или хотя бы описанная схема данных, а не бытовуха уровня "валидации форм". Но надо все же понимать, что ситуации разные, задача, в которой вопрос по алгоритму, в котором фигурирует ошибочное $_GET и вообще заведомо неверное решение непонятного контекста, не нужно изобретать лишних сущностей. Здесь человек еще даже не PHP изучает, а пытается управлять данными как таковыми. Но опять-таки, в зависимости от ситуации intval — нормальное решение. В данном случае гарантирует правильное сравнение в эфемерном примере.

[FanatPHP]

ты слишком уходишь в сторону
я тебе говорю об общих принципах
например, есть общий принцип, если страница не найдена - отдавать 404, если ошибка - 500, если нет доступа - 403
понятно что большинство похапе говнокода этим не заморачивается и на всё отдаёт 200. но это не значит что это правильно
в случае, если на вход система ожидает число, а приходит строка или массив, по-хорошему мы должны вернуть 400, а не молча проглатывать приводя к нулю. Это более правильно как в плане архитектуры самой системы, так и в лане ее взаимодействия с внешними клиентами

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

[Gennady S]

FanatPHP, в данном случае это непринципиально, а предмет отдельной темы. Все предметные области охватить в одном ответе невозможно, и отдельный совет плода не принесет, поскольку контекст неизвестен (есть там у автора validate_concrete_request_schema($_GET) или нет). Это эфемерный пример в порядке ответа на отдельный вопрос. Не рабочий код и не рекомендация по смежным темам.

К слову, 400 уместно для API (не для Ajax-компонент, например), и то, не для всех, даже несмотря на стандарты де-факто (лично я не сторонник обработки исключений в рамках бизнес-логики, порядка try-catch, и даже если это работает в рамках api как then/catch — в некотором смысле это моветон, но с этим приходится мириться, например, в случае RESTful, подходы которого распространились далеко за его рамки) — приложение может быть построено как гипотетически безошибочное, и все аспекты его работы могут рассматриваться как стандартные ситуации. 404, 403, etc — отдельная тема, поскольку по стандарту HTTP означает доступ к ресурсу как таковому, они не призваны обрабатывать ситуации бизнес-логики, на службу к которым поставили другие HTTP-заголовки. И это в общем-то не мое мнение, а давно известная критика использования неприспособленного к таким вещам протокола. Ну, не для этого HTTP создавался и в этом плане устарел. По идее, приложение должно возвращать ресурс, описывающий результат работы как тело, а не смешивать протокол HTTP и бизнес-логику. Тоже самое касается обработки исключений, долгое время считалось паттерном, что приложение не должно содержать исключительных ситуаций, сейчас на это вешают даже валидацию (к примеру), что имхо бред: try { $validator->check() } catch (ValidationException ...) { response(400); }

[FanatPHP]

ты опять растекаешься мыслью по древу и начинаешь спорить с какими-то отсуствующими здесь оппонентами
в то время как изначально была очень короткая ремарка, с которой лично я не вижу причин дискутировать: не нужно обрабатывать заведомо мусорный запрос

[Gennady S]

FanatPHP, задача не в обработке запроса, а в алгоритмике. Мое мнение, не стоит кичиться и поучать, кто и чего в школе проходил, или не проходил. Ни Вы, ни я, не лучшие специалисты, чтобы бить себя в грудь и шипеть на каждую опечатку или на начинающих разработчиков.

[FanatPHP]

а, ты про это
а я про коммент от necrodeflorator

Answer 2

[Dmitry]

if(in_array($_GET['year'], ['2016', '2017', '2018', '2019', '2020', '2021', '2022', '2023', '2024', '2025'])) {
	$jndns['year'] = $_GET['year'];
}

https://www.php.net/manual/ru/function.in-array.php

Comments

[Adamos]

В мануале по ссылке как раз стоит посмотреть на третий параметр. По умолчанию сравнение нечеткое.
Вот так вопрос нуба с помощью эксперта немного вправляет мозги нам, считающим себя опытными ;)

[Dmitry]

Adamos, да, по умолчанию сравнение нечеткое, как и в самом вопросе.

[FanatPHP]

Adamos, ну вроде бы, когда строки сравниваются, то косяков не должно быть.
во всяком есть мою проверку с 2016 поросят этот код пройдёт

[Adamos]

FanatPHP, да, не должно. Это уже я начал на воду дуть.

Answer 3

[Adamos]

Без задачи вопрос не имеет смысла. Например, вот это тоже ответ:

$jndns['year'] = min(2024, max(2016, $_GET['year']));

Comments

[FanatPHP]

это не ответ, а домыслы
за такие "решения" в приличном обществе бьют канделябрами

Answer 4

[Антон Р.]

if(isset($_GET['year']) && is_numeric($_GET['year']) && (strlen($_GET['year']) === 4))) {
  $jndns['year'] = $_GET['year'];
}

Comments

[FanatPHP]

$_GET['year'] = 2020;