Значення за замовчуванням - вони добрі чи злі?

12

Питання про значення за замовчуванням взагалі - значення функцій повернення за замовчуванням, значення параметрів за замовчуванням, логіка за замовчуванням, коли щось не вистачає, логіка за замовчуванням для обробки винятків, логіка за замовчуванням для обробки крайових умов тощо.

Тривалий час я вважав значення за замовчуванням "чистою злом", що є "маскує катастрофу" і призводить до того, що дуже важко знайти помилки. Але нещодавно я почав думати про значення за замовчуванням як про якусь технічну заборгованість ... це не зовсім погана річ, але те, що могло б забезпечити деяке "короткострокове фінансування", змусить нас пережити проект (скільки з нас може собі дозволити купити будинок, не виймаючи заставу?).

Коли я кажу "короткий термін" - я не маю на увазі - "зробіть щось швидше спочатку і зробіть його рефактор пізніше, перш ніж він потрапить у виробництво". Ні - я кажу про те, що покладатися на твердо кодовані значення за замовчуванням у виробничому програмному забезпеченні. Звичайно, це може спричинити деякі проблеми, але що робити, якщо це призведе лише до однієї проблеми протягом цілого року.

Знову ж таки - я говорю про тут "середнє" програмне забезпечення (не програмне забезпечення для атомної електростанції) - середній веб-сайт або додаток для користувальницького інтерфейсу для програмного забезпечення бухгалтерського обліку, що означає, що життя людей не загрожує, ні мільйони доларів .

Знову ж таки, з мого досвіду, бізнес-користувачі скоріше живуть із програмним забезпеченням, яке "працює якось", а не чекають ідеального. І використання значень за замовчуванням дуже допомагає, якщо ви розробляєте програмне забезпечення у стилі RAD. Але знову ж таки - найдовші сесії налагодження, які я провів, були через помилки, введені значенням за замовчуванням, яке або перестало бути "за замовчуванням" по дорозі, або через те, що невелика підсистема нещодавно була оновлена, і в результаті цього оновлення це не відбувається правильно обробляти за замовчуванням (наприклад, порожній список проти нуля або нульовий рядок проти порожнього рядка).

Тому моє запитання - чи є значення за замовчуванням добром чи злом. І якщо вони є технічним боргом - як виміряти, скільки ви можете позичити, щоб ви могли дозволити собі виплати?

Буду дуже вдячний за будь-який внесок.

Ура.

Редагувати:

Якщо я використовую значення за замовчуванням як спосіб вирізати кути під час розробки - і якщо вирізання кутів призводить до помилок і проблем - яка методологія відновлення цих проблем?

programming-practices

24

Концепція Конвенції про конфігурацію неможлива без розумних значень за замовчуванням. Ключове слово тут - «розумне». Значення за замовчуванням мають мати сенс щонайменше для 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адресний рядок?

— Йорг W Міттаг

1

Отже, як вимірювати / оцінювати / оцінювати рівень чистоти змінної за замовчуванням.

5

Скільки часу потрібно продумати розумне значення за замовчуванням.

— Олександр Гесслер

1

@Andrew, дивіться мою відповідь нижче. Якщо значення добре для 80% або більше використання, це хороший дефолт.

— Берін Лорич

2

@Berin Loritsch: Якщо значення за замовчуванням використовується для відмови безпечно, ви можете стверджувати, що це добре навіть тоді, коли воно використовується лише 1% часу.

— oosterwal

18

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

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

Крім того, обробка виключень "catch-all" - це, мабуть, вада дизайну, а не все, що можна назвати "за замовчуванням".

— Рей Міясака
джерело

Гаразд, "catch-all" насправді є хорошим прикладом. Так - це викликає багато горя, коли колись щось піде не так з якоїсь невідомої причини, і ці "деякі" здебільшого невідомі, оскільки реальний виняток був загублений у загальноприйнятому блоці. Так це погано - правда? З іншого боку - без блоку загального програмного забезпечення програмне забезпечення може взагалі вмирати (якщо виняток не обробляється), або вимагатиме складної логіки обробки помилок (принаймні, доведеться зафіксувати виняток та ініціалізувати деякі дані за допомогою значення за замовчуванням).

Отже, щоб додати моє первісне запитання - якщо я використовую значення за замовчуванням як спосіб вирізати кути під час розробки - і якщо вирізання кутів призводить до помилок і проблем - який найкращий спосіб відновитись із цих проблем?

1

Що стосується винятків, є стаття, в якій сказано, що має бути один виняток для всіх викликів на кожну нитку , якщо вона взагалі є. Він буде використовуватися для повідомлення про помилки, тому ви дивитесь на програму як на єдину "річ" так само, як і в ОС на процес. Оскільки ви маєте кінцевого споживача (і, сподіваємось, розробників) у циклі, ви насправді не «ковтаєте» виняток - тому все добре. Стаття тут: codeproject.com/KB/architecture/exceptionbestpractices.aspx

— Rei Miyasaka

1

Що стосується використання за замовчуванням, щоб уникнути помилок - як щодо використання послідовного коментаря, яким ви можете керувати + f / mac + f? Наприклад, Visual Studio фактично показує будь-який коментар, який починається зі TODO: or TEMP:списку завдань. Якщо я коли-небудь вирізаю кут заради розвитку, я намагаюся бути надзвичайно обережним, щоб переконатися, що я поставив TODO туди - тоді, раз у раз, я зроблю "знайду всіх", щоб повернутися назад і переконатися ніщо з цього не потрапляє у будь-які важливі побудови.

— Рей Міясака

Ну, я мав на увазі використання твердо кодованих значень, щоб допомогти розвитку. До речі, я щойно зрозумів, що "жорстко закодовані значення" - це, мабуть, слово, яке ви шукаєте, а не "значення за замовчуванням".

— Rei Miyasaka

3

За замовчуванням слід використовувати, коли вони рятують користувача або розробника від виконання завдань, що повторюються. Їх ніколи не слід використовувати для маскування помилок чи винятків. Це не погана практика використовувати їх для запобігання помилок, але лише до тих пір, поки запобігання не маскує щось погане. Значення за замовчуванням - це інструмент, як і все інше. Правильно використані вони можуть заощадити багато головного болю та часу. Неправильно використані вони можуть збити весь будинок.

— Джоел Етертон
джерело

На кшталт C ++, що відбиває всю ногу ...

— Mateen Ulhaq

1

@muntoo: Гей, Лісп мені дав кульгавість ще в03 році.

— Джоель Етертон

3

Першопричиною проблем, які ви цитуєте, є не значення за замовчуванням самі по собі, а проблеми інтеграції через зміну договорів інтерфейсу, непорозуміння інтерпретації та / або недійсні припущення. В основному всі ці (конкретні приклади) здаються результатом неправильного спілкування - між клієнтом і розробником, або між різними розробниками / командами. Досить справедливо, ці проблеми можуть проявлятися як недійсні значення за замовчуванням, але також у незліченних кількох формах.

Впорайтеся з першопричиною, а не симптомом.

І також зауважте, що - як зазначають інші на відмінних прикладах - значення за замовчуванням при розумному використанні можуть значно полегшити життя користувачів. І це, зрештою, наша мета, чи не так?

— Петер Тьорк
джерело

"Неправильне спілкування" може бути першопричиною, але чи не першопричиною це майже нічого? А оскільки "моя кінцева мета" - вчасно доставити "достатньо хороше" програмне забезпечення у обмежених витратах умовах, я хотів знати, як сказати про добрі / злі дефолти від хороших.

@Andrew, спілкування (або його відсутність) є головним фактором успіху / провалу проекту, але далеко не єдиним. Однак, коли він є винуватцем, з ним слід поводитися належним чином, інакше ваш проект майже напевно приречений. Я не знаю жодного магічного інструменту для відокремлення поганих значень за замовчуванням від хороших: IMHO вимагає ретельного аналізу проблемної області, використання справ тощо та, ну, багато спілкування.

— Péter Török

1

Значення за замовчуванням, які не є частиною протоколу / конвенції зв'язку, є злими. Будучи "не частиною", я маю на увазі, що вони не задокументовані там, де протокол є суворим, або їх просто не очікують, коли протокол розслаблений.

Якщо значення за замовчуванням задокументовано / очікується, воно все одно може бути злим, але воно також може врятувати життя. Це залежить від області домену. Це дуже часто, коли вони можуть бути дуже небезпечними (наприклад, дозування ліків за замовчуванням, ліфт за замовчуванням, ліфт за замовчуванням, напрямок руху автомобіля за замовчуванням), а іноді може бути небезпечним і не мати їх (наприклад, напрямок руху автомобіля за замовчуванням, час зустрічі за замовчуванням).

— астеф
джерело