Valores padrão - eles são bons ou maus?

A pergunta sobre valores padrão em geral - valores de função de retorno padrão, valores de parâmetro padrão, lógica padrão para quando algo está faltando, lógica padrão para tratamento de exceções, lógica padrão para tratamento de condições de borda etc.

Por um longo tempo, considerei os valores padrão uma coisa "pura maldade", algo que "encobre a catástrofe" e resulta em um erro muito difícil de encontrar. Mas, recentemente, comecei a pensar nos valores padrão como uma espécie de dívida técnica ... o que não é uma coisa ruim, mas algo que poderia fornecer algum "financiamento de curto prazo" nos leva a sobreviver ao projeto (quantos de nós poderiam pagar comprar uma casa sem tirar a hipoteca?).

Quando digo um "curto prazo" - não quero dizer - "faça algo rapidamente primeiro e refatore-o mais tarde, antes que atinja a produção". Não - estou falando de confiar em valores padrão codificados em um software de produção. Concedido - isso pode causar alguns problemas, mas e se apenas causar um único problema em um ano inteiro.

Novamente - eu estou falando sobre o software convencional "médio" aqui (não é um software para uma usina nuclear) - o site médio ou um aplicativo de interface do usuário para o software de contabilidade, o que significa que a vida das pessoas não está em jogo, nem milhões de dólares .

Novamente, pela minha experiência, os usuários corporativos preferem viver com o software que "funciona de alguma forma", em vez de esperar por um perfeito. E o uso de valores padrão ajuda muito se você desenvolver um software no estilo RAD. Mas novamente: as sessões de depuração mais longas que passei foram por causa dos erros introduzidos por um valor padrão que deixou de ser "padrão" ao longo do caminho ou porque um pequeno subsistema foi atualizado recentemente e, como resultado dessa atualização, não é manipule o padrão corretamente (por exemplo, lista vazia vs nulo ou seqüência nula vs seqüência vazia).

Então, minha pergunta é - os valores padrão são bons ou maus. E se eles são uma dívida técnica - como medir quanto você pode emprestar para poder pagar os reembolsos?

Realmente apreciaria qualquer entrada.

Felicidades.

EDITAR:

Se estou usando os valores padrão como uma maneira de cortar os cantos durante o desenvolvimento - e se o corte dos cantos resultar em bugs e problemas - qual é a metodologia para recuperar esses problemas?

O conceito de Convenção sobre configuração é impossível sem valores padrão sensíveis . A palavra-chave aqui é "sensata". Os valores padrão precisam fazer sentido para pelo menos 80% (se não mais) de todos os usos de uma biblioteca / serviço / estrutura.

Regras gerais gerais:

• Se um valor for sensível para 80% ou mais usos, ele precisará ser um valor padrão
• Se não houver valores usados ​​na maioria dos casos, não use padrões.
• Os valores padrão evitam erros estúpidos do código de instalação. Se os padrões são razoáveis ​​para a maioria dos casos, menos pessoas mexem com a configuração de trabalho.
• Configurações não padrão são mais visíveis quando você usa padrões.
• Padrões ruins são piores que nenhum padrão.

Essencialmente, depois de aprender como a configuração padrão funciona, você pode tomar decisões informadas sobre como / quando fazer configurações não padrão.

Tomemos, por exemplo, uma biblioteca que implementa o protocolo FTP. Por padrão, espera-se que o FTP opere na porta 21. Agora, ficaria muito irritado se tivesse que especificar o uso da porta 21 toda vez que construir um objeto de uma classe FTP aleatória. Se eu precisar de uma porta diferente, deixe-me especificar.

Os padrões são perfeitamente bons quando são padrões saudáveis.

Você provavelmente está usando um layout de teclado padrão com mapeamentos de teclas padrão, mapeamentos de botões do mouse padrão, o navegador padrão, digitando no idioma padrão do sistema, inicializando no sistema operacional padrão no carregador de inicialização, menus posicionados padrão, esquema de cores padrão e fonte padrão largura / altura / face / estilo, conjunto de caracteres padrão, resolução padrão do monitor, padrão ... você entendeu.

Mas, com toda a seriedade, acho que a preocupação que você está tendo não é com os padrões, mas com outra coisa. O comportamento padrão não mascara de forma inerente os erros. Na maioria das vezes, seu código será executado em condições comuns de qualquer maneira, independentemente de você definir ou não os padrões. Casos não controlados são coisas que você deseja evitar, independentemente (presumivelmente através de testes adequados e adequados), para quando os padrões forem alterados ou um cenário incomum.

Além disso, o tratamento de exceção "catch-all" é sem dúvida uma falha de design, e não qualquer coisa que você possa chamar de "padrão".

Os padrões devem ser usados ​​quando eles salvam o usuário ou desenvolvedor de executar tarefas repetitivas. Eles nunca devem ser usados ​​para mascarar erros ou exceções. Não é uma prática ruim usá-los para evitar erros, mas apenas desde que a prevenção não oculte que algo de ruim está acontecendo. Os valores padrão são uma ferramenta como todo o resto. Quando usados ​​adequadamente, você pode economizar muita dor de cabeça e tempo. Utilizados indevidamente, podem derrubar a casa inteira.

A causa raiz dos problemas citados não são os valores padrão propriamente ditos, mas os problemas de integração devido a alterações nos contratos de interface, mal-entendidos de interpretação e / ou suposições inválidas. Basicamente, todos esses (exemplos específicos) parecem resultar de comunicação inadequada - entre cliente e desenvolvedor ou entre diferentes desenvolvedores / equipes. Justamente, esses problemas podem se manifestar como valores padrão inválidos, mas também de inúmeras outras formas.

Lidar com a causa raiz, não o sintoma.

E observe também que, como outros salientaram com excelentes exemplos, os valores padrão, quando usados ​​com sabedoria, podem facilitar significativamente a vida dos usuários. E esse é o objetivo final, não é?

Os valores padrão que não fazem parte do protocolo / convenção de comunicação são maus. Por "não fazer parte", quero dizer que eles não estão documentados onde o protocolo é rigoroso, ou simplesmente não são esperados, onde o protocolo está solto.

Se o valor padrão é documentado / esperado, ainda pode ser ruim, mas também pode ter vidas seguras. Depende da área do domínio. Muitas vezes, eles podem ser muito perigosos (por exemplo, dosagem padrão do remédio, piso padrão do elevador, direção do movimento do carro) e, às vezes, pode ser perigoso não tê-los (por exemplo, direção do movimento do carro, horário padrão da reunião).