Проверка “Даты рождения”: Как далеко/очень Вы пошли бы?

будучи перфекционистом, я бы пошел сюда за 150: D

как ни малейшие шансы, люди уже прошли 120, и кто знает, что произойдет в ближайшие 30 лет: D

Однако я не считаю это таким важным ..

Все зависит от приложения. Бизнес-приложение для обработки заказов сильно отличается от отслеживания исторических или будущих данных.

Можно согласиться, что это должна быть действительная дата, но учтите, что существует несколько календарей (например, номер месяца может быть 13, год может быть больше 5000).

Давайте везде будем использовать двузначные годы. После 1999 года никто не будет использовать наше программное обеспечение!

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

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

Если вы беспокоитесь о «непонятливости». или вводимые ботами, затем используйте Captcha. Сказав все это, я считаю, что вы в безопасности с используемыми вами правилами проверки.

Что ж, я не программист (скорее бакалавр), хотя я пытаюсь получить некоторые навыки разработки, поскольку я думаю, что это может помочь мне стать лучше бакалавром. Я' немного поработал с VBA (не смейтесь).

В общем, размышляя об этом, вот мои два цента

1) Отказ от юмора. То, что вам сейчас смешно, никому не будет. Более того, то, что смешно после двух или трех ходов, не смешно после 25 или 30 - это просто утомительно, даже если вы имеете дело с анекдотами! 2) Я прихожу к мысли, что, если вы не можете окончательно подтвердить что-то как явное неправильное, например, вы не хотите, чтобы кто-то вводил значение <0, тогда вам следует подумать о предупреждении, а не о предотвращении с помощью диалогов или чего-то еще.

Эй, что я знаю? Через неделю я передумал (я бизнес-аналитик) и буду требовать немедленных ответов от разработчиков; ->

Проверять на целое число и быть полезным; Я думаю, что все остальное: оскорбительная / старшая / чрезмерно изощренная система - плохая идея.

Людям должно быть позволено лгать на этих формах, если они хотят; это не закон, это веб-сайт.

Не воспринимайте это так серьезно.

Если вы делаете это для чего-то профессионального, например, для подачи заявления на работу, я бы не стал использовать "!" в сообщениях пользователям. Взгляните на любой хорошо сделанный веб-сайт, который вам нужен, вы не найдете его широко используемого.

Спрашивая живых людей о дате их рождения, отвергайте только те значения, которые определенно неверны. Любая дата рождения в будущем определенно неверна. И я бы хотел провести черту и сказать, что любая дата рождения до (скажем) 1880 года определенно неверна. Все остальное является допустимой датой рождения.

Таким образом, любая дата рождения, не прошедшая вышеуказанные тесты, отклоняется с сообщением на уровне поля, например «Эта дата находится в будущем / слишком далеко в прошлом. Пожалуйста, введите свою дату рождения».

Любая другая дата рождения действительна (возможно, пользователю действительно 11 или 108 лет). Но общая форма может быть отклонена бизнес-правилами. Например, «Вам должно быть не менее 18 лет, чтобы подавать заявку»

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

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

Так что для вашего приложения может быть что-то вроде этого:

• Age
• Возраст> общепринятый возраст выхода на пенсию - предупреждение
• Возраст> ожидаемая продолжительность жизни - ошибка

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

В частности, меня всегда беспокоит логический порядок вещей. Если кто-то говорит, что они родились в 1802 году, это нормально (вроде как), я просто хочу, чтобы дата их окончания была больше даты их рождения. Но вы сталкиваетесь с небольшими неприятными проблемами, когда дело касается времени (например, часов и минут), например, если пользователь выбирает 8:30 в качестве времени начала, а затем выбирает 9:15 в качестве времени окончания, но затем понимает, что время окончания было 8:45. Они решили изменить 9 на 8 с намерением изменить минуты на: 45. Но мой сценарий проверки слишком занят, говоря: «Эй, погоди! 8:15 до 8:30, хорошая попытка!» Но я могу' Я рискую позволить им оставить все неправильно и т. д.

Конкретно для вашей ситуации я бы склонился к тому, что является этическим правом. Поскольку, как уже отмечалось, кто-то может вводить семейный анамнез (с датами рождения в 1600-х годах) или будущие покупки (с датами после сегодняшнего дня), поэтому в целом нет реалистичного ограничения на даты. Но у вашего сценария есть ограничения, например:

Если возраст ниже установленного законом трудоспособного возраста (16 в большинстве частей США), даже не предлагайте ничего выше этого года в качестве варианта (если вы используете drop вниз).

Если возраст превышает разумный трудоспособный возраст (который может быть деликатным вопросом), предложите наивысшее значение, основанное на пенсионном возрасте, и просто добавьте «>» перед этим годом. Если кому-то 75 лет и он подает заявку на должность администратора, им будет больше приятно, что вы сделали все просто, а не обидно, что вы не указали год их рождения. Во всяком случае, они будут впечатлены (я думаю), что вы пошли этим путем, а не совсем ничего, подразумевая, что им не следует тратить свое время.

В конце концов, у вас есть простой выпадающий список, который очень легко написать скриптом (пример PHP):

$currentYear = date('Y');

    echo "<select name=\"YearOfBirth\">";

for($i = 16; $i <= 64; $i++) {
    $optionYear = $currentYear - $i;
    echo "<option value=\"$optionYear\">$optionYear</option>";
    }

    $greaterYear = $currentYear - 65;
    echo "<option value=\"&gt;$greaterYear\">&gt;$greaterYear</option>";

    echo "</select>";

Проверка и правильность
Точка проверки входных данных состоит в том, чтобы убедиться, что все элементы находятся в разрешенном и ожидаемом диапазоне при дальнейшей обработке, т.е. если ваша база данных гарантирует все заявители в БД - 18 лет и старше, подтвердите это. Если ваша база данных также принимает школьников, подавших заявления на стажировку, не делайте этого.

Все необычное - всего лишь предупреждение. Да, значение 120 лет - это безумие, вы должны предупредить пользователя и, возможно, пометить эту запись как подозрительную / для проверки. Однако нет смысла отклонять его (если у вас нет бизнес-правила, согласно которому, например, все кандидаты моложе 70 лет).

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

Вся дальнейшая обработка - человеком или компьютером - все равно должна предполагать, что DOB может быть неверным - только из-за опечатка. Вы пытаетесь создать гарантию, которую на самом деле не можете дать. Многие пользователи доверяют компьютеру, которым пользуются каждый день больше, чем незнакомцу, вы пытаетесь навязать это доверие - что является ошибкой ИМО.

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

(Это, вероятно, помещает меня в серьезную категорию вашего клиента, но это мой способ быть »