Funzionalità linguistiche di programmazione che aiutano a catturare i bug in anticipo [chiuso]

Go ne ha alcuni:

1. Le importazioni inutilizzate sono errori (non sono sicuro che si tratti di cattura di errori, sicuramente di uno stile di codice buono)

2. Nessuna conversione implicita, var i int = .5 è un errore, non un avvertimento o un troncamento automatico.

3. Keying off di 2, essere strongmente tipizzati staticamente serve a catturare molti errori.

4. Tutto è 0 inizializzato (in modo ragionevole) quindi non ci sono puntatori nulli.

5. Una sorta di supporto per il test dell'unità integrato. Non ho approfondito questo argomento.

Un altro che mi viene in mente è Haskell

1. Scritto in modo strongmente statico. Chiedi a qualsiasi Haskeller riguardo al sistema di tipi, esso rileva il 99% dei miei errori di haskell prima ancora che riesca a eseguirlo.

2. Progettare per contratto in misura Int->Int->Int anche se questo sarebbe incapsulato nella maggior parte delle dichiarazioni di funzione nelle lingue

3. Puramente funzionale. Se una funzione funziona una volta in uno scenario, funzionerà sempre.

Tuttavia, in generale, le buone pratiche in una lingua con scarsa sicurezza battono un programmatore disattento in un linguaggio sicuro. Prendiamo ad esempio C (Non è un jab in C, ma si appoggia di più sull'utente per ricontrollare che le cose sono sane) chiaramente è possibile scrivere un buon codice robusto in C nonostante la mancanza di funzionalità per questo. Alla fine il programmatore > linguaggio di programmazione.

Inizia guardando nel linguaggio di programmazione Ada originale dal 1983. Ada è stato progettato specificamente per scrivere sistemi altamente affidabili che avrebbero cicli di vita molto lunghi.

strong tipizzazione statica. strong semantica Facilmente leggibile Composto incorporato.

Puoi hackerare fino a farti scoppiare, ma devi LAVORARE su di esso, e il codice risultante SEMBRA piaccia. Questa è una caratteristica: avvisa il prossimo pessimo programma di manutenzione che Here Be Dragons.

C'è un'osservazione dagli albori dell'informatica: correre con il controllo degli iscritti abilitato durante il pagamento e spegnerlo per la produzione è come indossare il giubbotto di salvataggio nel porto e poi toglierlo quando esci in mare aperto. Tieni presente che Ada richiedeva che il controllo degli indici fosse attivato per impostazione predefinita e richiedeva ai programmatori di disattivarlo in modo esplicito se fossero così in grassetto.

Alcuni test che vorrei avere (probabilmente non tutti ininterrottamente):

• Test al contorno : molti errori si verificano sui limiti del dominio (come mettere < invece di <= ). Quindi se potessi in qualche modo supportare questo, sarebbe grato. (Lascia che il programmatore definisca int[0-90] e quindi nessun valore superiore a 90 o inferiore a 0 sarà consentito).
• Test di robustezza : è quasi uguale a quanto sopra, ma mira a testare valori che non dovrebbero essere supportati e vedere che l'app non si arresta in modo anomalo.
• Quanto sopra può essere combinato con un test - > il software non si arresta e verifica solo valori casuali dell'intero dominio (numeri casuali, stringhe casuali)
• Conoscenza del dominio : un buon modo per inserire i test da parte degli esperti di dominio sarà buono. Ciò significa che qualcuno che ha una conoscenza molto buona nel settore bancario, ma nessun indizio nella programmazione dovrebbe essere in grado di scrivere alcuni test, secondo la sua conoscenza.
• Grafico del programma : crea un grafico del programma, inclusi rami e loop. E mentre esegui una serie di test, segna le linee del codice testato e quelle che non sono mai state toccate. Quindi il programmatore \ tester può sapere quale parte del codice non è mai stata testata. (Potrebbe essere il tempo e lo spazio necessario)
• Assertimenti : offre al programmatore un'opzione per fare un asserimento durante il test, che verrà ritirato dal compilatore in produzione. Questa è un'idea molto antica che nessuno ha veramente implementato in modo positivo (se non del tutto).