Come evitare errori di battitura, ecc.?

Hai già risposto alla tua domanda da solo.

Ci sono molte cose che dovresti sempre ricordare durante lo sviluppo (indipendentemente dalla lingua, IDE, il progetto è sulla tua scrivania):
- Durante lo sviluppo, prova a pensare solo sul progetto su cui stai lavorando. Tutto il resto dovrebbe essere dimenticato per un po ', comprese le lodi che otterrai se fai bene il tuo lavoro. Questi pensieri ti distraggono e farai più errori come risultato.
- Non fare fretta , se non è vitale per il progetto. Prenditi il tuo tempo, prova a testare tutto correttamente. Come hai detto, il codice scritto in modo rapido ma pieno di bug non è qualcosa di cui essere orgogliosi. Sono sicuro che se non ti sbrighi così tanto sarai in grado di rilevare molti bug da solo.

E, come menzionato in altre risposte, esegui i test unitari. E ancora uno. Ci saranno SEMPRE dei bug. Nessuno è perfetto. Ma queste due regole ti aiuteranno a ridurre la loro quantità.

I do run tests, but sometime they miss these errors (incomplete test coverage).

Dopo che il tuo errore è stato scoperto, considera l'aggiunta di un nuovo test che impedisca ai futuri contributori di ripetere questo errore o, meglio ancora, un tipo di errore come questo.

Se fatto bene, migliorare la copertura dei test e i test di regressione probabilmente compenseranno in misura sufficiente il danno causato dal tuo errore.

- L'approccio del buon senso sarà taking your time e rivedrai il tuo codice prima di contrassegnare il tuo lavoro. Inoltre, prova a maximize your focus/concentration per la tranquillità del lavoro che ti è stato assegnato.

- Primo approccio pratico utilizzerebbe una volta re-factoring tools like JustCode o simili. Avrebbero improve your productivity e potresti perfezionarlo per errori di sintassi .

- Secondo approccio pratico utilizzerebbe lo approccio TDD . Si assicurerà che il tuo codice abbia i test necessari per funzionare (supererà tutti i test di unità richiesti), altrimenti fallirà.

Sebbene TDD abbia bisogno di tempo per implementare e rifattorizzare il codice esistente secondo necessità, è un modo pulito per scrivere un codice affidabile e solido.

Dipende dal linguaggio di programmazione. Una lingua con una tipizzazione statica e una fase di compilazione nel processo di compilazione cattureranno la maggior parte degli errori di battitura; più severa è la lingua, maggiore è la probabilità di errore di battitura a causare una sintassi non valida. Un esempio estremo è il linguaggio di programmazione Haskell - i programmatori di Haskell spesso affermano, quasi scherzosamente, che una volta compilato un programma Haskell, di solito è corretto e privo di errori. Ci sono ancora errori di battitura che scivolano attraverso la rete però; un famoso esempio è = vs. == in C / C ++. Lo stile di codifica può fornire una protezione aggiuntiva; l'analisi del codice statico può rilevare codice sospetto; un editor di testo con completamento automatico riduce la possibilità di errori di battitura; ma alla fine, non esiste alcun sostituto per i test effettivi.

Se si utilizza un linguaggio dinamico, le cose sono più difficili - in genere, non vi è alcun passo di compilazione, quindi gli errori tutti vengono visualizzati come errori di runtime, nessuno di questi impedisce la distribuzione per natura. Peggio ancora, molti errori verranno rilevati solo dopo l'esecuzione del codice incriminato. Questo rende i test (automatizzati) ancora più vitali rispetto ai rigorosi linguaggi compilati staticamente.

Ma poi i test automatici hanno il loro problema: la copertura. Affinché i test automatizzati catturino tutti gli errori, è necessario il 100% di copertura del codice (ovvero i test devono toccare ogni singola riga di codice), ma occorre anche una copertura di input del 100% (i test devono chiamare ogni unità con ogni possibile insieme di input , in ogni possibile stato del contesto). La copertura del 100% del codice è fattibile, ma la copertura del 100% dell'input è difficilmente impossibile per tutto ciò che non è banale. La cosa migliore è fare ipotesi plausibili su insiemi di input che potrebbero colpire i casi limite e sperare di non perdere nessuno. E poiché i test sono (per necessità) scritti dagli umani, puoi commettere errori mentre scrivi i test, proprio come puoi commettere degli errori mentre scrivi il codice da testare. Fortunatamente, il più delle volte, un bug nel test non cancella un bug nel codice testato, ma fa sì che il test fallisca doppiamente.

Ecco cosa puoi fare per prevenire e mitigare gli errori di battitura:

• Sii religioso riguardo al test unitario di tutto.
• Configura il tuo ambiente di sviluppo per eseguire automaticamente tutti i test: se hai un sistema di integrazione continua, configuralo per eseguire tutti i test di unità su ogni build e considera qualsiasi build interrotta se un test fallisce. Altrimenti, considera l'utilizzo di hook di controllo del codice sorgente o funzionalità simili per eseguire i test prima di spingere le modifiche a monte.
• Codice in modo difensivo, evita trucchi "intelligenti", usa le caratteristiche dinamiche in modo conservativo.
• Se il tuo linguaggio di programmazione ha opzioni per essere più rigoroso (ad esempio Option Strict e Option Explicit in VisualBasic), attivale.
• Se il tuo linguaggio di programmazione può mettere in guardia sul codice sospetto, fallo in modo (non sui sistemi di produzione) e considera ogni avviso come un errore fatale.
• Fai buon uso delle protezioni incorporate nella lingua (ad esempio il suggerimento di tipo PHP).
• Utilizza un editor di codice che fornisce il completamento automatico; usalo.
• Durante la denominazione degli identificatori, evita "near-misses": non utilizzare $User e $user nello stesso contesto.
• Mantieni il tuo ambito il più possibile locale e piccolo: evita lo stato globale, esponi solo ciò che devi, evita gli effetti collaterali, ecc. Evita di toccare accidentalmente oggetti in luoghi completamente indipendenti e semplifica il test del codice.
• Chiedi a qualcun altro di rivedere il tuo codice.

Nessuno di questi è a prova di proiettile, ma combinarli copre la maggior parte delle basi e riduce il rischio a, si spera, livelli accettabili.

Ho continuato a commettere errori stupidi simili. La soluzione che ho trovato era il test unitario. Hai creato una serie di test automatici per verificare la correttezza del tuo codice mentre lo scrivi.

Scrivi il tuo codice in una lingua compilata .

EDIT: non sto proponendo che questa sia una soluzione a prova di proiettile, ma sicuramente ti aiuterà a evitare molti refusi.

Trova qualcuno in grado di esaminare il tuo codice senza metterti in imbarazzo.

Uno dei tuoi problemi è che pensi di perdere la faccia quando l'intero progetto rivede il tuo codice e trova errori. Forse c'è qualcuno nel progetto o meno con cui puoi fare coppia per guardare il tuo codice. Schermate, screencast, patch, lavoro su un altro ramo, ecc., Uno qualsiasi di questi metodi può essere usato per condividere il codice prima che il resto del team del progetto possa vederlo.

In cambio, naturalmente, dovresti offrire lo stesso o qualche altro servizio a quella persona, ad esempio se raddoppi come artista puoi fornire icone o qualsiasi altra cosa di cui hanno bisogno.

Assicurati che un errore passato non possa ripetersi

Questo è più facile in una lingua dattiloscritta, ma se trovi che a volte scrivi $ thsi invece di $, per esempio, abilita il correttore ortografico del tuo editore. Se è qualcosa di più coinvolto, prova a scrivere un caso di test che lo cattura.

Ad esempio, un paio di volte ho commesso degli errori durante la modifica dei file di proprietà utilizzati per l'internazionalizzazione, in modo tale che non vi fosse alcun valore in inglese per alcune chiavi. Ho corretto i file e poi ho scritto un test che caricava tutte le chiavi in una volta sola e se mancava ne mancavano alcune.

Investi in strumenti e lingue migliori

Se c'è un editor migliore di quello che stai usando, usalo. Se c'è un linguaggio migliore di quello che stai usando, usalo. Certamente, "meglio" dipende da vari fattori, uno dei quali è il codice che hai già nel progetto. Se la lingua di destinazione è davvero pessima, potresti addirittura generare codice da una lingua migliore. Ci sono cose che perdi, ma è bene essere consapevoli di questa opzione. In pratica ho dovuto farlo solo una volta, quando ho dato alcuni requisiti per un codice Java molto ripetitivo che doveva essere completamente documentato. Ho generato 3000 righe di codice Java da 50 righe di un'altra lingua.

Una libreria di ortografia come Hunspell o Aspell può essere integrato nel tuo programma:

library(hunspell)

# Check individual words
words <- c("beer", "wiskey", "wine")
correct <- hunspell_check(words)
print(correct)
# [1]  TRUE FALSE  TRUE

il tuo editor:

olatuapipelinedibuild:

spellcheckHTML:image:tmaier/hunspell:latestscript:-exportHUNSPELL_FINDINGS='hunspell-l-iUTF-8-dde_DE_neu,en_US-p.words-Hpublic/**/*.html|sort|uniq'-echo$HUNSPELL_FINDINGS-test"$HUNSPELL_FINDINGS" == ""
dependencies:
  - build
stage: test
allow_failure: true

Crea un file dizionario personalizzato per il controllo ortografico specifico del progetto utilizzando la funzionalità "Aggiungi al dizionario" del tuo editor di scelta.

Riferimenti

• Il pacchetto hunspell: Stemmer ad alte prestazioni, Tokenizer e Controllo ortografico per R

• Correzione ortografica di parole errate in Python usando HunSpell | Blog di WZB Data Science

• FAQ Dipartimento di Matematica dell'Università dello Utah: Controllo ortografico

• Modifica dei dizionari di controllo ortografico - The Chromium Projects

• Aggiunta di dizionari personalizzati e elenchi di termini

• hunspell Numero # 448: Hunspell nella pipeline CI

• dizionari Hunspell in UTF-8

• Come installare i dizionari manualmente · Numero 62 · Predelnik / DSpellCheck

• Sonetto KDE: controllo ortografico

• Come installare un dizionario di piattaforma in Eclipse - Stack Overflow