От лени реализовал третий вариант. Думаю, стоит ли запиливать новый слой абстракции для второго варианта или перепиливать логику для реализации первого варианта.
Но, уважаемый, этот вариант спасает файлы/железо/ОС невнимательных и неопытных пользователей, хотя и не гарантирует сохранность их нервных клеток.
Мой преподаватель по программированию и архитектуре ЭВМ всегда говорил: человек/пользователь должен четко знать и представлять то, чего он желает.
Я же развиваю и углубляю тему: Абстрактные желания/выражения в консоли могут привести к нежелательным и, порой фатальным, последствиям.
Негласное правило/стандарт при программировании обработчика входных параметров для приложения - при неверных входных параметрах/данных останавливать процесс выполнения и выдавать соответствующее сообщение.
Меня так учили.
P.S. Если программа, запущенная без параметров не производит никаких изменений в окружающей среде, то ВСЕ параметры просто могут быть проигнорированы, а программа запущена на выполнение с параметрами по-умолчанию.
И мы со всего размаху врезались (аки в стену лбом) в достаточно старый спор: необходимо ориентироваться на новичка, который ничего не соображает, или же на подготовленного пользователя, который прекрасно отдаёт себе отчёт в том, что именно он сейчас делает. Я сторонник второго подхода. По той причине, что убеждён -- пока досконально не изучил предмет нехрен туда лезть. Ведь никто не садится за руль автомобиля без обучения. Почему с компьютером должно быть по другому?
Зато обучает великолепно! Стоило мне отключить "корзины" во всей фирме, где я тогда админил, как бездумное удаление файлов сошло на нет. Правда, перед этим поверещали... :-)
Если параметр важный, от него зависит работоспособность программы,сохранность данных и т д, надо сообщать об ошибке и больше не продолжать выполнение.
Если параметр не очень важен и есть какое-то значение по-умолчанию, то тут уже можно отсеивать неправильные значения и подставлять то, которое по-умолчанию. Но опять же, всё зависит от задачи. В графических приложениях очень удобно использовать "валидатор", это проверка значений которые вводятся например в LineEdit и подобные виджеты.
извините, но замена неправильного параметра умолчательным втихую это, на мой взгляд, самый неприемлемый вариант. получается программа начинает жить своей жизнью, выходит из под контроля. опять вы же сами кричите везде, что линукс позволяет полностью контролировать систему, а здесь предлагаете вариант полностью противоположный.
в данном случае мне видится три варианта:
1. вывод сообщения об ошибке и выход.
2. вывод предупредительного сообщения и предложение вариантов обхода проблемы (например, как в аптитьюд).
3. пока писал два предыдущих, забыл )))
Первый вариант считаю самым правильным. Иначе зачастую приходилось бы отказывать назад выполненную частично команду и перевыполнять её со всеми правильными параметрами. А это уже куча лишних телодвижений. Да, вначале может раздражать, если что-то указал неправильно, но зато это во-первых безопасно и во-вторых снимает ряд лишних телодвижений в случае части ошибочно введённых параметров. Проходит немного времени и ошибок уже не делаешь. Зато параметры вводишь правильно.
Надо просто делать поля ввода которые не допускают ввод некоректных параметров. Ввод по маске. Вроде так. Т.е. если в поле должны быть числа, то ввод текста игнорируется. Буквы просто не вводятся. Можно еще поступить как делают в некоторых программах, в которых вводится пароль, и они высвечивают всплывающее сообщение с предупреждением. Например "У вас зажата клавиша CapsLock". Применительно к генератору рандома это может быть всплывающая подсказка с текстом "Слишком большое число". Обязательно прямо в поле ввода, а не в трее. Конечно это не спасет от тех, кто постоянно смотрит на клавиатуру, когда набирает текст. В этом случае можно еще воспроизвести предупреждающий сигнал. Но конечно и это не панацея. У пользователя может быть выключен звук.
Генератор случайных чисел по заданным параметрам =)
А это графическая прога? На каком языке? Если графическая и на Qt, то "Запретить ввод букв" - это не проблема. Могу подсказать как сделать.
Комментарии (27)
От лени реализовал третий вариант. Думаю, стоит ли запиливать новый слой абстракции для второго варианта или перепиливать логику для реализации первого варианта.
Второй вариант представляется как более информативным, так и более щадящим. Первый вариант реализован сейчас в Linux и это несказанно раздражает.
Но, уважаемый, этот вариант спасает файлы/железо/ОС невнимательных и неопытных пользователей, хотя и не гарантирует сохранность их нервных клеток.
Мой преподаватель по программированию и архитектуре ЭВМ всегда говорил: человек/пользователь должен четко знать и представлять то, чего он желает.
Я же развиваю и углубляю тему: Абстрактные желания/выражения в консоли могут привести к нежелательным и, порой фатальным, последствиям.
Негласное правило/стандарт при программировании обработчика входных параметров для приложения - при неверных входных параметрах/данных останавливать процесс выполнения и выдавать соответствующее сообщение.
Меня так учили.
P.S. Если программа, запущенная без параметров не производит никаких изменений в окружающей среде, то ВСЕ параметры просто могут быть проигнорированы, а программа запущена на выполнение с параметрами по-умолчанию.
С файлами работа не ведётся. На данный момент неверным параметрам задаётся значение по умолчанию.
И мы со всего размаху врезались (аки в стену лбом) в достаточно старый спор: необходимо ориентироваться на новичка, который ничего не соображает, или же на подготовленного пользователя, который прекрасно отдаёт себе отчёт в том, что именно он сейчас делает. Я сторонник второго подхода. По той причине, что убеждён -- пока досконально не изучил предмет нехрен туда лезть. Ведь никто не садится за руль автомобиля без обучения. Почему с компьютером должно быть по другому?
Не, явно не на подготовленного пользователя.
Тогда и думать не о чем -- первый вариант.
Мнэээ... надавать вводящему недопустимый результат по рукам железной линейкой, чтобы больше так не делал?
Очень уж негуманно.
Зато обучает великолепно! Стоило мне отключить "корзины" во всей фирме, где я тогда админил, как бездумное удаление файлов сошло на нет. Правда, перед этим поверещали... :-)
Тут ещё всё зависит от типа параметров и типа программы. Вариантов много.
Генератор случайных чисел по заданным параметрам =)
и далее выбор партиции для форматирования на основании выданных генератором числа. )))
да, и конечно же, запуска форматирования в фоновом режиме. )))
Дать пробничек? ]:->
ноу, фенкс ;)
Если параметр важный, от него зависит работоспособность программы,сохранность данных и т д, надо сообщать об ошибке и больше не продолжать выполнение.
Если параметр не очень важен и есть какое-то значение по-умолчанию, то тут уже можно отсеивать неправильные значения и подставлять то, которое по-умолчанию. Но опять же, всё зависит от задачи. В графических приложениях очень удобно использовать "валидатор", это проверка значений которые вводятся например в LineEdit и подобные виджеты.
извините, но замена неправильного параметра умолчательным втихую это, на мой взгляд, самый неприемлемый вариант. получается программа начинает жить своей жизнью, выходит из под контроля. опять вы же сами кричите везде, что линукс позволяет полностью контролировать систему, а здесь предлагаете вариант полностью противоположный.
в данном случае мне видится три варианта:
1. вывод сообщения об ошибке и выход.
2. вывод предупредительного сообщения и предложение вариантов обхода проблемы (например, как в аптитьюд).
3. пока писал два предыдущих, забыл )))
Первый вариант считаю самым правильным. Иначе зачастую приходилось бы отказывать назад выполненную частично команду и перевыполнять её со всеми правильными параметрами. А это уже куча лишних телодвижений. Да, вначале может раздражать, если что-то указал неправильно, но зато это во-первых безопасно и во-вторых снимает ряд лишних телодвижений в случае части ошибочно введённых параметров. Проходит немного времени и ошибок уже не делаешь. Зато параметры вводишь правильно.
Надо просто делать поля ввода которые не допускают ввод некоректных параметров. Ввод по маске. Вроде так. Т.е. если в поле должны быть числа, то ввод текста игнорируется. Буквы просто не вводятся. Можно еще поступить как делают в некоторых программах, в которых вводится пароль, и они высвечивают всплывающее сообщение с предупреждением. Например "У вас зажата клавиша CapsLock". Применительно к генератору рандома это может быть всплывающая подсказка с текстом "Слишком большое число". Обязательно прямо в поле ввода, а не в трее. Конечно это не спасет от тех, кто постоянно смотрит на клавиатуру, когда набирает текст. В этом случае можно еще воспроизвести предупреждающий сигнал. Но конечно и это не панацея. У пользователя может быть выключен звук.
На случай выключенного звука должна быть световая индикация: Экран ярко вспыхивает всеми цветами радуги.
Слишком большие числа не страшны. Запретить ввод букв — интересная идея, но я ничего не встречал такого =(
А это графическая прога? На каком языке? Если графическая и на Qt, то "Запретить ввод букв" - это не проблема. Могу подсказать как сделать.
На данный момент есть гуйня на Tk и wx =)
В wx есть wxValidator.
Сенкс, потыкаем =)
Не реализовано в биндингах к python...
Отправить комментарий