Ci sono vantaggi nel codificare i valori dei dati in un programma?

12

Sono un programmatore autodidatta e alle prime armi, quindi mi scuso se non annullo il gergo del programmatore.

Sto lavorando a un progetto in cui sto fornendo dati, che saranno continuamente aggiornati, agli sviluppatori che essenzialmente creeranno uno strumento per generare report dalle query sui dati.

Sembra che tutte le persone coinvolte credano di aver bisogno di codificare i valori dei dati (non lo schema, ma i domini / i valori stessi) nel programma di generazione dei report.

Ad esempio, supponiamo di riferire sul personale; il rapporto verrebbe suddiviso in categorie, con un'intestazione per ciascun dipartimento, quindi sotto ogni intestazione di reparto saranno presenti sottotitoli di titoli di lavoro, quindi sotto ogni sottotitolo sarà presente un elenco di dipendenti. Gli sviluppatori vogliono hard-code i dipartimenti e titoli di lavoro. D'altra parte, penserei che avrebbero / avrebbero dovuto interrogare queste cose in fase di runtime, ordinare i record da loro e generare intestazioni di report dinamicamente in base a quali valori ci sono.

Poiché l'elenco dei valori potenziali cambierà nel tempo (ad esempio, i reparti verranno creati / rinominati, verranno aggiunti nuovi titoli di lavoro), il codice dovrà essere continuamente aggiornato. Mi sembra che potremmo saltare i passaggi di manutenzione del codice e organizzare dinamicamente i rapporti.

Poiché non sono uno sviluppatore, mi chiedo cosa mi sfugge. Quali vantaggi potrebbero esserci per i valori hard-coding in uno strumento come questo? Questo è tipicamente come sono progettati i programmi?

    
posta Tom 09.08.2016 - 20:09
fonte

4 risposte

9

Wikipedia:

Hard coding (also hard-coding or hardcoding) refers to the software development practice of embedding what may, perhaps only in retrospect, be considered an input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

L'hard-coding è considerato un antipattern.

Considered an anti-pattern, hard coding requires the program's source code to be changed any time the input data or desired format changes, when it might be more convenient to the end user to change the detail by some means outside the program.

A volte non puoi evitarlo ma dovrebbe essere temporaneo.

Hard coding is often required. Programmers may not have a dynamic user interface solution for the end user worked out but must still deliver the feature or release the program. This is usually temporary but does resolve, in a short term sense, the pressure to deliver the code. Later, softcoding is done to allow a user to pass on parameters that give the end user a way to modify the results or outcome.

  • L'hardcoding dei messaggi rende difficile l'internazionalizzazione di un programma.
  • I percorsi di codifica hardware rendono difficile l'adattamento a un'altra posizione.

L'unico vantaggio di hardcoding sembra essere la rapida consegna del codice.

    
risposta data 09.08.2016 - 21:38
fonte
23

Davvero? Nessun possibile caso d'uso valido?

Pur essendo d'accordo che hardcoded è generalmente un anti-pattern o almeno un pessimo odore di codice , lì ci sono molti casi in cui ha senso:

  • semplicità ( YAGNI ),
  • l'input è effettivamente costante e non cambierà mai (cioè rappresenta una costante naturale o commerciale o un'approssimazione di uno, ad esempio 0, PI, ...),
  • software incorporato (vengono in mente i vincoli di memoria e allocazione)
  • software sicuro (questi valori non sono disponibili e / o facili da decodificare o decodificare, ad esempio token e sali crittografici),
  • codice generato (il tuo preprocessore o generatore è configurabile, ma sputa codice con valori hard-coded),
  • e probabilmente ancora.

Ancora un Anti-Pattern ? Così è Over-Engineering ! Riguarda l'aspettativa di vita del tuo software !!

Non sto dicendo che ci sono tutti ottimi motivi, e in generale mi ritrovo con i valori codificati. Ma alcuni possono ottenere facilmente un pass per validi motivi.

E non sorvegliare il primo per semplicità / YAGNI o pensando che sia banale: probabilmente non c'è motivo di implementa un parser pazzo e un controllo dei valori per un semplice script che fa un lavoro molto bene per un caso d'uso ristretto.

È difficile trovare l'equilibrio. A volte non prevedi che un software possa crescere e durare più a lungo del semplice script che ha iniziato. Spesso però è il contrario: noi sovrintendiamo le cose e un progetto viene archiviato più velocemente di quanto tu possa leggere il Pragmatic Programmer. Hai sprecato tempo e sforzi sulle cose di quanto non fosse necessario un prototipo iniziale.

Queste sono le cose cattive con Anti-Pattern: sono presenti in entrambi gli estremi dello spettro e il loro aspetto dipende dalla sensibilità della persona che controlla il tuo codice.

    
risposta data 09.08.2016 - 22:08
fonte
5

Ci sono volte in cui va bene i valori hard-code. Ad esempio, ci sono alcuni numeri come 0, o uno o vari valori n ^ 2-1 per le maschere di bit che devono essere determinati valori per scopi algoritmici. Consentire tali valori al configurabile non ha valore e apre solo la possibilità di problemi. In altre parole, se la modifica di un valore interromperebbe solo le cose, dovrebbe probabilmente essere codificata in modo rigido.

Nell'esempio che hai dato, non vedo dove sarebbe utile l'hard-coding. Tutto ciò che menzioni dovrebbe / dovrebbe già essere nel database, inclusi i titoli. Anche le cose che guidano la presentazione (come l'ordinamento) possono essere aggiunte se non ci sono.

    
risposta data 09.08.2016 - 21:53
fonte
-1

L'implementazione di una soluzione robusta che consente di configurare valori che altrimenti potrebbero essere stati codificati per essere configurabili dagli utenti finali richiede una valida convalida di tali valori. Hanno messo una stringa vuota? Hanno inserito qualcosa di non numerico dove avrebbe dovuto essere un numero? Stanno facendo l'iniezione SQL? Ecc.

L'hard coding evita molti di questi rischi.

Il che non vuol dire che l'hard-coding sia sempre, o anche spesso, una buona idea. Questo è solo uno dei fattori da tenere in considerazione.

    
risposta data 11.08.2016 - 20:48
fonte