Valori predefiniti: sono buoni o cattivi?

12

La domanda sui valori predefiniti in generale: valori della funzione di ritorno predefiniti, valori dei parametri predefiniti, logica predefinita per quando manca qualcosa, logica predefinita per la gestione delle eccezioni, logica predefinita per la gestione delle condizioni dei bordi, ecc.

Per molto tempo ho considerato i valori di default come una cosa "malvagia", qualcosa che "nasconde la catastrofe" e si traduce in una ricerca di bug molto difficile. Ma recentemente ho iniziato a pensare ai valori di default come a una sorta di debito tecnico ... che non è una cosa negativa, ma qualcosa che potrebbe fornire alcuni "finanziamenti a breve termine" ci fa sopravvivere al progetto (quanti di noi potrebbero permettersi comprare una casa senza sottoscrivere il mutuo?).

Quando dico un "breve termine" - non voglio dire - "fai prima qualcosa velocemente e poi rifatturalo prima che colpisca la produzione". No - Sto parlando di fare affidamento su valori predefiniti codificati in un software di produzione. Concesso: potrebbe causare alcuni problemi, ma cosa succederebbe se causasse un solo problema in un anno intero.

Ancora una volta - sto parlando del software mainstream "medio" qui (non un software per una centrale nucleare) - il sito Web medio o un'applicazione UI per il software di contabilità, il che significa che le persone non sono in gioco, né milioni di dollari .

Ancora una volta, per mia esperienza, gli utenti aziendali preferiscono vivere con il software che "funziona in qualche modo", piuttosto che aspettare quello perfetto. E l'uso di valori predefiniti aiuta molto se si sviluppa un software in stile RAD. Ma ancora una volta - le sessioni di debug più lunghe che ho trascorso sono state a causa dei bug introdotti da un valore predefinito che ha smesso di essere "predefinito" lungo il percorso o perché un piccolo sottosistema è stato recentemente aggiornato e come risultato di questo aggiornamento non lo fa gestire correttamente il valore predefinito (ad es. elenco vuoto vs null o stringa null vs stringa vuota).

Quindi la mia domanda è: i valori predefiniti sono buoni o cattivi. E se si tratta di un debito tecnico, come si misura l'importo che si può prendere in prestito in modo da potersi permettere i rimborsi?

Gradirei davvero qualsiasi input.

Saluti.

MODIFICARE:

Se sto usando i valori predefiniti come modo per tagliare gli angoli durante lo sviluppo - e se il taglio degli angoli si traduce in bug e problemi - qual è la metodologia per recuperare da questi problemi?

programming-practices

23

Il concetto di convenzione sulla configurazione è impossibile senza valori predefiniti sensibili . La parola chiave qui è "sensibile". I valori predefiniti devono avere senso per almeno l'80% (se non di più) di tutti gli usi di una libreria / servizio / framework.

Regole generali:

Se un valore è ragionevole per l'80% o più di utilizzi, deve essere un valore predefinito
Se non ci sono valori utilizzati nella maggior parte dei casi, non utilizzare i valori predefiniti.
I valori predefiniti impediscono errori stupidi dal codice di installazione. Se le impostazioni predefinite sono ragionevoli per la maggior parte dei casi, un minor numero di persone confonde con la configurazione di lavoro.
Le configurazioni non standard sono più visibili quando si utilizzano le impostazioni predefinite.
Bad impostazioni predefinite sono peggio di non predefiniti.

In sostanza, una volta appreso come funziona la configurazione predefinita, è possibile prendere decisioni ponderate su come / quando eseguire configurazioni non standard.

— Berin Loritsch
fonte

Grazie per avermi indicato il concetto di "Convenzione sulla configurazione". L'ho usato senza sapere che ha un nome. Puoi spiegare questa regola: "Le configurazioni non standard sono più visibili quando si utilizzano le impostazioni predefinite". per favore.

3

@Andrew se c'è una dozzina di chiamate Foo()e una chiamata a Foo("bar"), quella chiamata tende a distinguersi ed è quindi più visibile.

— Matthew Scharley,

1

Giusto, e se la maggior parte degli usi di un servizio FTP usa new FtpService()quello che imposta una porta alternativa si distinguerà ( service.SetPort(12345)).

— Berin Loritsch,

43

Prendiamo ad esempio una libreria che implementa il protocollo FTP. Per impostazione predefinita, l'FTP dovrebbe funzionare sulla porta 21. Ora sarei molto irritato se dovessi specificare di utilizzare la porta 21 ogni volta che costruisco un oggetto di una classe FTP casuale. Se ho bisogno di una porta diversa, lasciatemi specificare.

I valori predefiniti sono perfettamente validi quando si tratta di valori predefiniti sani.

— Htbaa
fonte

21

+1. Quando è stata l'ultima volta che hai digitato http://programmers.stackexchange.com:80/questions/?sort=newest&pagesize=50una barra degli indirizzi?

— Jörg W Mittag,

1

Quindi, come si misura / stima / etto un livello di integrità della variabile predefinita.

5

Quanto tempo ci vuole per pensare a un valore di default ragionevole.

— Alexander Gessler,

1

@Andrew, vedi la mia risposta qui sotto. Se un valore è valido per l'80% o più di utilizzi, è un buon valore predefinito.

— Berin Loritsch,

2

@Berin Loritsch: se il valore predefinito viene utilizzato per un errore sicuro, si potrebbe sostenere che è buono anche quando viene utilizzato solo l'1% delle volte.

— oosterwal,

18

Probabilmente stai utilizzando un layout di tastiera predefinito con mappature dei tasti predefinite, mappature dei pulsanti del mouse predefiniti, browser predefinito, digitazione nella lingua predefinita del sistema, avvio dal sistema operativo predefinito nel caricatore di avvio, menu posizionati per impostazione predefinita, combinazione di colori predefinita, carattere predefinito larghezza / altezza / faccia / stile, set di caratteri predefinito, risoluzione monitor predefinita, impostazione predefinita ... si ottiene l'idea.

Ma con tutta serietà, penso che la preoccupazione che stai avendo non sia con le impostazioni predefinite ma con qualcos'altro. Il comportamento predefinito non maschera intrinsecamente i bug. Il più delle volte il tuo codice verrà eseguito in condizioni comuni, indipendentemente dal fatto che tu abbia impostato o meno le impostazioni predefinite. I casi limite non gestiti sono cose che vorresti assicurarti di evitare indipendentemente (presumibilmente attraverso test adeguati e adeguati), per quando le impostazioni predefinite vengono modificate o si verifica uno scenario non comune.

Inoltre, la gestione delle eccezioni "catch-all" è probabilmente un difetto di progettazione piuttosto che qualsiasi cosa che si possa definire "predefinita".

— Rei Miyasaka
fonte

OK, "catch-all" in realtà è un buon esempio. Sì, sta causando molto dolore quando un giorno qualcosa va storto per qualche motivo sconosciuto, e questi "alcuni" sono sconosciuti in gran parte perché la vera eccezione è stata persa in un blocco generale. Quindi è una brutta cosa - giusto? D'altra parte - senza un blocco generale il software potrebbe morire del tutto (se l'eccezione non viene gestita) o richiederebbe una logica di gestione degli errori complicata (almeno dovrebbe registrare l'eccezione e inizializzare alcuni dati con un valori standard).

Quindi, per aggiungere alla mia domanda originale - se sto usando i valori predefiniti come modo per tagliare gli angoli durante lo sviluppo - e se il taglio degli angoli si traduce in bug e problemi - qual è il modo migliore per recuperare da questi problemi?

1

Per quanto riguarda le eccezioni, c'è un articolo che dice che dovrebbe esserci un'eccezione generale per ogni thread , se ne esiste una. Sarebbe usato per la segnalazione degli errori, quindi stai guardando il programma come una singola "cosa" allo stesso modo in cui il sistema operativo guarderebbe un processo. Dal momento che hai l'utente finale (e, si spera, gli sviluppatori) nel loop, in realtà non stai "ingoiando" l'eccezione, quindi va tutto bene. Articolo qui: codeproject.com/KB/architecture/exceptionbestpractices.aspx

— Rei Miyasaka

1

Per quanto riguarda l'uso delle impostazioni predefinite per evitare bug - che ne dici di usare un commento coerente che puoi controllare + f / mac + f? Ad esempio, Visual Studio mostra effettivamente qualsiasi commento che inizia con TODO: or TEMP:nell'elenco delle attività. Se dovessi mai tagliare un angolo per lo sviluppo, cerco di essere estremamente attento a assicurarmi di mettere un TODO lì - poi, una volta ogni tanto, farò un "trova tutto" per tornare indietro e assicurarmi niente di tutto ciò entra in build importanti.

— Rei Miyasaka,

Spiacenti, intendevo usare valori codificati per aiutare lo sviluppo. A proposito, ho appena capito che "valori codificati" è probabilmente la parola che stai cercando, piuttosto che "valori predefiniti".

— Rei Miyasaka,

3

I valori predefiniti devono essere utilizzati quando salvano l'utente o lo sviluppatore dall'esecuzione di attività ripetitive. Non dovrebbero mai essere usati per mascherare errori o eccezioni. Non è una cattiva pratica usarli per prevenire errori, ma solo fintanto che la prevenzione non maschera qualcosa di brutto. I valori predefiniti sono uno strumento come tutto il resto. Se usati correttamente possono farti risparmiare un sacco di mal di testa e tempo. Se usati in modo improprio possono far crollare l'intera casa.

— Joel Etherton
fonte

Un po 'come il C ++ che ti fa saltare tutta la gamba ...

— Mateen Ulhaq,

1

@muntoo: Ehi, Lisp mi ha dato un debole nel '03.

— Joel Etherton,

2

La causa principale dei problemi citati non sono i valori predefiniti di per sé, ma i problemi di integrazione dovuti alla modifica dei contratti di interfaccia, incomprensioni interpretative e / o ipotesi non valide. Fondamentalmente tutti questi (esempi specifici) sembrano essere il risultato di una comunicazione impropria - tra client e sviluppatore o tra diversi sviluppatori / team. Abbastanza giusto, questi problemi possono manifestarsi come valori predefiniti non validi, ma anche in innumerevoli altre forme.

Gestire la causa principale, non il sintomo.

E nota anche che, come altri hanno sottolineato con esempi eccellenti, i valori predefiniti, se usati con saggezza, possono semplificare notevolmente la vita degli utenti. E quello è in definitiva il nostro obiettivo, no?

— Péter Török
fonte

"Comunicazione impropria" potrebbe essere la causa principale, ma non è una causa principale per praticamente nulla? E poiché "il mio obiettivo finale" è quello di fornire un software "abbastanza buono" in tempo in un ambiente a costi ridotti, volevo sapere come distinguere i valori predefiniti male / male da quelli buoni.

@Andrew, la comunicazione (o la sua mancanza) è un fattore determinante per il successo / fallimento di un progetto, ma lungi dall'essere l'unico. Tuttavia, quando è il colpevole, dovrebbe essere trattato correttamente, altrimenti il tuo progetto è quasi sicuramente condannato. Non conosco nessuno strumento magico per separare le impostazioni predefinite errate da quelle buone: IMHO richiede un'attenta analisi del dominio del problema, casi d'uso ecc. E, beh, molta comunicazione.

— Péter Török,

0

I valori predefiniti che non fanno parte del protocollo / convenzione di comunicazione sono malvagi. Essendo "non una parte" intendo che non sono documentati dove il protocollo è rigoroso, o semplicemente non sono previsti, dove il protocollo è sciolto.

Se il valore predefinito è documentato / previsto, può comunque essere malvagio, ma può anche salvare vite. Dipende dall'area del dominio. È molto spesso quando possono essere molto pericolosi (ad es. Dosaggio di medicina predefinito, pavimento dell'ascensore predefinito, direzione di spostamento della macchina predefinita), e talvolta può essere pericoloso non averli (ad esempio direzione di spostamento della macchina predefinita, orario di riunione predefinito).

— astef
fonte