Значения по умолчанию - это добро или зло?

12

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

Долгое время я считал значения по умолчанию «чистым злом», то, что «скрывает катастрофу» и приводит к очень трудным поискам ошибок. Но недавно я начал думать о значениях дефолта как о каком-то техническом долге ... что не так уж плохо, но что-то, что могло бы обеспечить "краткосрочное финансирование", чтобы заставить нас выжить в проекте (сколько из нас могли себе позволить купить дом без ипотеки?).

Когда я говорю «на короткий срок» - я не имею в виду - «сначала сделайте что-нибудь быстро и сделайте рефакторинг позже, прежде чем это произойдет». Нет - я говорю о том, чтобы полагаться на жестко заданные значения по умолчанию в производственном программном обеспечении. Конечно, это может вызвать некоторые проблемы, но что, если это вызовет только одну проблему за целый год.

Опять же - я имею в виду «среднее» основное программное обеспечение здесь (не программное обеспечение для атомной электростанции) - средний веб-сайт или приложение для пользовательского интерфейса для бухгалтерского программного обеспечения, означающее, что жизнь людей не поставлена ​​на карту, ни миллионы долларов ,

Опять же, исходя из моего опыта, бизнес-пользователи предпочитают жить с программным обеспечением, которое «работает как-то», а не ждать идеального. И использование значений по умолчанию очень помогает, если вы разрабатываете программное обеспечение в стиле RAD. Но опять же - самые длинные сеансы отладки, которые я провел, были из-за ошибок, внесенных значением по умолчанию, которое либо перестало быть «по умолчанию», либо потому, что недавно была обновлена ​​небольшая подсистема, и в результате этого обновления она не правильно обрабатывать значения по умолчанию (например, пустой список или пустая строка или пустая строка или пустая строка).

Поэтому мой вопрос - являются ли значения по умолчанию добром или злом. И если это технический долг - как определить, сколько вы можете одолжить, чтобы позволить себе выплаты?

Был бы очень признателен за любой вклад.

Приветствия.

РЕДАКТИРОВАТЬ:

Если я использую значения по умолчанию как способ обрезать углы во время разработки - и если обрезка углов приводит к ошибкам и проблемам - какова методология для устранения этих проблем?

programming-practices
источник

Ответы:

23

Концепция Соглашения по Конфигурации невозможна без разумных значений по умолчанию. Ключевое слово здесь - «разумный». Значения по умолчанию должны иметь смысл как минимум для 80% (если не больше) всех использований библиотеки / службы / инфраструктуры.

Общие правила:

  • Если значение подходит для 80% и более применений, оно должно быть значением по умолчанию
  • Если в большинстве случаев отсутствуют значения, не используйте значения по умолчанию.
  • Значения по умолчанию предотвращают глупые ошибки из кода установки. Если значения по умолчанию приемлемы для большинства случаев, меньше людей возятся с рабочей конфигурацией.
  • Нестандартные конфигурации более заметны при использовании значений по умолчанию.
  • Плохие значения по умолчанию хуже, чем отсутствие значений по умолчанию.

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

Берин Лорич
источник
Спасибо, что указали мне на концепцию «Соглашение о конфигурации». Я использовал его, не зная, что у него есть имя. Можете ли вы объяснить это правило: «Нестандартные конфигурации более заметны при использовании значений по умолчанию». Пожалуйста.
3
@ Andrew, если есть дюжина звонков Foo()и один звонок Foo("bar"), этот звонок имеет тенденцию выделяться и, следовательно, более заметен.
Мэтью Шарли
1
Правильно, и если в большинстве случаев использование службы FTP будет использовать new FtpService()тот, который устанавливает альтернативный порт ( service.SetPort(12345)).
Берин Лорич
43

Возьмем, к примеру, библиотеку, которая реализует протокол FTP. По умолчанию ожидается, что FTP будет работать через порт 21. Теперь я был бы очень раздражен, если бы мне приходилось указывать использовать порт 21 каждый раз, когда я создаю объект случайного класса FTP. Если мне нужен другой порт, позвольте мне указать.

Значения по умолчанию прекрасно подходят, когда они являются нормальными значениями.

Htbaa
источник
21
+1. Когда вы в последний раз вводили http://programmers.stackexchange.com:80/questions/?sort=newest&pagesize=50в адресную строку?
Йорг Миттаг
1
Итак, как вы измерите / оцените / оцените уровень разумности переменной по умолчанию.
5
Сколько нужно времени, чтобы подумать о разумном значении по умолчанию.
Александр Гесслер
1
@ Андрей, посмотри мой ответ ниже. Если значение подходит для 80% и более применений, это хорошее значение по умолчанию.
Берин Лорич
2
@Berin Loritsch: Если значение по умолчанию используется для безопасного сбоя, вы можете утверждать, что это хорошо, даже если оно используется только 1% времени.
oosterwal
18

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

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

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

Рей Миясака
источник
ОК, «ловить все» на самом деле является хорошим примером. Да - это вызывает много горя, когда однажды что-то идет не так по неизвестной причине, и эти «некоторые» неизвестны в основном потому, что настоящее исключение было потеряно в универсальном блоке. Так что это плохо - верно? С другой стороны - без блока всеохватывающего программного обеспечения программа может либо вообще умирать (если исключение не обрабатывается), либо потребовать сложной логики обработки ошибок (по крайней мере, для этого потребуется зарегистрировать исключение и инициализировать некоторые данные с помощью значения по умолчанию).
Итак, чтобы добавить к моему первоначальному вопросу - если я использую значения по умолчанию как способ обрезать углы во время разработки - и если обрезка углов приводит к ошибкам и проблемам - каков наилучший способ исправить эти проблемы?
1
Что касается исключений, то есть статья, в которой говорится, что должно быть одно исключение для всех потоков , если оно вообще есть. Он будет использоваться для отчетов об ошибках, поэтому вы рассматриваете программу как отдельную «вещь» так же, как ОС смотрит на процесс. Поскольку у вас есть конечный пользователь (и, надеюсь, разработчики) в цикле, вы на самом деле не «проглатываете» исключение - так что все хорошо. Статья здесь: codeproject.com/KB/architecture/exceptionbestpractices.aspx
Рей Миясака
1
Что касается использования значений по умолчанию, чтобы избежать ошибок - как насчет использования последовательного комментария, которым вы можете управлять + f / mac + f? Например, Visual Studio фактически показывает любой комментарий, который начинается TODO: or TEMP:в списке задач. Если я когда-нибудь выберу угол для развития, я постараюсь быть предельно осторожным, чтобы убедиться, что я поместил туда TODO - тогда, время от времени, я сделаю «найти все», чтобы вернуться и убедиться, ничего из этого не входит в какие-либо важные сборки.
Рей Миясака
К сожалению, я имел в виду использование жестко закодированных значений, чтобы помочь развитию. Кстати, я только что понял, что «жестко заданные значения» - это, вероятно, слово, которое вы ищете, а не «значения по умолчанию».
Рей Миясака
3

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

Джоэл Этертон
источник
Вроде как C ++,
отрывающий
1
@muntoo: Привет, Лисп хромал в 2003 году.
Джоэл Этертон
3

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

Обработайте основную причину, а не симптом.

Также обратите внимание, что, как другие отмечали на отличных примерах, значения по умолчанию, если их использовать с умом, могут значительно облегчить жизнь пользователям. И это в конечном итоге наша цель, не так ли?

Петер Тёрёк
источник
«Неправильное общение» может быть основной причиной, но разве это не является основной причиной чего-либо? И поскольку «моей конечной целью» является своевременное предоставление «достаточно хорошего» программного обеспечения в условиях ограниченных затрат, я хотел знать, как отличить плохие / злые значения по умолчанию от хороших.
@ Андрей, общение (или его отсутствие) является основным фактором успеха / провала проекта, но далеко не единственным. Тем не менее, когда это виновник, с ним нужно обращаться должным образом, иначе ваш проект почти наверняка обречен. Я не знаю ни одного волшебного инструмента для отделения плохих значений по умолчанию от хороших: ИМХО требует тщательного анализа предметной области, вариантов использования и т. Д., А также большого количества общения.
Петер Тёрёк
1

Значения по умолчанию, которые не являются частью протокола / соглашения о связи, являются злыми. Под «не частью» я подразумеваю, что они не задокументированы там, где протокол строгий, или они просто не ожидаемы, где протокол свободен.

Если значение по умолчанию задокументировано / ожидаемо, оно все равно может быть злым, но оно также может спасти жизнь. Это зависит от области домена. Это очень часто, когда они могут быть очень опасными (например, стандартная дозировка лекарств, этаж лифта по умолчанию, направление движения автомобиля по умолчанию), и иногда это может быть опасно, если их нет (например, направление движения автомобиля по умолчанию, время встречи по умолчанию).

astef
источник