2014-04-26 10:52:28 -04:00
|
|
|
restriction
|
|
|
|
|
|
2014-04-26 11:54:15 -04:00
|
|
|
n. A bug or design error that limits a program's capabilities, and which is
|
|
|
|
|
sufficiently egregious that nobody can quite work up enough nerve to
|
|
|
|
|
describe it as a feature. Often used (esp. by marketroid types) to make it
|
|
|
|
|
sound as though some crippling bogosity had been intended by the designers
|
|
|
|
|
all along, or was forced upon them by arcane technical constraints of a
|
|
|
|
|
nature no mere user could possibly comprehend (these claims are almost
|
|
|
|
|
invariably false). Old-time hacker Joseph M. Newcomer advises that whenever
|
|
|
|
|
choosing a quantifiable but arbitrary restriction, you should make it either
|
|
|
|
|
a power of 2 or a power of 2 minus 1. If you impose a limit of 107 items in
|
|
|
|
|
a list, everyone will know it is a random number on the other hand, a limit
|
|
|
|
|
of 15 or 16 suggests some deep reason (involving 0- or 1-based indexing in
|
|
|
|
|
binary) and you will get less flamage for it. Limits which are round numbers
|
|
|
|
|
in base 10 are always especially suspect.
|
|
|
|
|
|
