= 27d567bc2d48d9f40e9ccc20ea370b15)
Lumifer comments on The horrifying importance of domain knowledge - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (236)
Actually, the proper solution is to practice defensive programming, not trust the user input, and be generous with sanity checks. Failing gracefully is much easier when your software knows it's not in Kansas any more.
Which sounds nice right up until a production system shuts itself down gracefully a few hours before a daylights saving time switch purely because of tests which turn out to be more picky than the actual thing they're supposed to be protecting.
Multi-byte characters can do surprising things to scripts designed to truncate logs written by someone who didn't take into account the maximum size of characters and chinese production server names.
A lot of a programmers day can end up being related to fixing bugs due to incorrect assumptions or failing to take edge cases into account and knowing lots of edge cases and handling a reasonable portion of them right away is far better than making the most restrictive possible assumptions off the bat.
You don't want to end up running into the Y2Gay problem: http://qntm.org/gay
Do you know that "the system" can handle that input fine? If you do, why did you sanity check reject it?
Sanity checks are just code -- you certainly can write bad ones. So?
That post argues via mind-numbingly stupid strawmen (or should that be strawschemas?). Yes, you should try to be not stupid, most of the time, to the best of your ability. I agree :-/