Best practice di programmazione difensiva preferita (intelligente) [chiuso]

Se dovessi scegliere le tue tecniche preferite (intelligenti) per la codifica difensiva, quali sarebbero? Sebbene le mie lingue attuali siano Java e Objective-C (con un background in C ++), sentiti libero di rispondere in qualsiasi lingua. L'enfasi qui sarebbe sulle tecniche difensive intelligenti diverse da quelle che il 70% + di noi qui già conosce. Quindi ora è il momento di scavare in profondità nella tua borsa di trucchi.

In altre parole, prova a pensare ad altro che a questo esempio poco interessante :

• if(5 == x) anziché if(x == 5) : per evitare incarichi non intenzionali

Ecco alcuni esempi di alcuni intriganti migliori pratiche di programmazione difensiva (esempi lingua-specifici sono in Java):

- Blocca le variabili fino a quando non sai che è necessario modificarle

Cioè, puoi dichiarare tutte le variabili finalfino a quando non sai che dovrai cambiarle, a quel punto puoi rimuovere il final. Un fatto comunemente sconosciuto è che questo è valido anche per i parametri del metodo:

public void foo(final int arg) { /* Stuff Here */ }

- Quando succede qualcosa di brutto, lascia dietro di sé una scia di prove

Ci sono molte cose che puoi fare quando hai un'eccezione: ovviamente registrarlo ed eseguire un po 'di pulizia sarebbe un paio. Ma puoi anche lasciare una scia di prove (ad esempio impostare variabili su valori sentinella come "IMPOSSIBILE CARICARE IL FILE" o 99999 sarebbe utile nel debugger, nel caso in cui ti catchimbatti in un blocco di eccezioni ).

- Quando si tratta di coerenza: il diavolo è nei dettagli

Sii coerente con le altre librerie che stai utilizzando. Ad esempio, in Java, se si sta creando un metodo che estrae un intervallo di valori, rendono compreso il limite inferiore e il limite superiore esclusivi . Ciò lo renderà coerente con metodi come quelli String.substring(start, end)che funzionano allo stesso modo. Troverai tutti questi tipi di metodi nel Sun JDK per comportarsi in questo modo in quanto esegue varie operazioni tra cui l'iterazione di elementi coerenti con gli array, in cui gli indici vanno da Zero ( incluso ) alla lunghezza dell'array ( esclusivo ).

Quali sono le tue pratiche difensive preferite?

Aggiornamento: se non lo hai già fatto, sentiti libero di intervenire. Sto dando la possibilità che arrivino più risposte prima di scegliere la risposta ufficiale .

In c ++, una volta mi piaceva ridefinire il nuovo in modo che fornisse un po 'di memoria in più per catturare gli errori post-recinzione.

Attualmente, preferisco evitare la programmazione difensiva a favore di Test Driven Development . Se si rilevano errori rapidamente ed esternamente, non è necessario confondere il codice con manovre difensive, il codice è DRY -er e si finisce con meno errori che si devono difendere.

Come ha scritto WikiKnowledge :

Evita invece la programmazione difensiva, fallisci velocemente.

Per programmazione difensiva intendo l'abitudine di scrivere codice che tenti di compensare qualche errore nei dati, di scrivere codice che presume che i chiamanti possano fornire dati non conformi al contratto tra chiamante e subroutine e che la subroutine deve in qualche modo far fronte con esso.

SQL

Quando devo cancellare i dati, scrivo

select *    
--delete    
From mytable    
Where ...

Quando lo eseguirò, saprò se ho dimenticato o pasticciato la clausola where. Ho una sicurezza. Se tutto va bene, metto in evidenza tutto dopo i token di commento '-' ed eseguo.

Modifica: se sto eliminando molti dati, userò count (*) anziché solo *

Allocare una porzione ragionevole di memoria all'avvio dell'applicazione - Penso che Steve McConnell si riferisse a questo come un paracadute di memoria in Code Complete.

Questo può essere usato nel caso in cui qualcosa di grave vada storto e ti viene richiesto di terminare.

Allocare questa memoria in anticipo fornisce una rete di sicurezza, in quanto è possibile liberarla e quindi utilizzare la memoria disponibile per effettuare le seguenti operazioni:

• Salva tutti i dati persistenti
• Chiudi tutti i file appropriati
• Scrivi messaggi di errore in un file di registro
• Presenta un errore significativo all'utente

In ogni istruzione switch che non ha un caso predefinito, aggiungo un caso che interrompe il programma con un messaggio di errore.

#define INVALID_SWITCH_VALUE 0

switch (x) {
case 1:
  // ...
  break;
case 2:
  // ...
  break;
case 3:
  // ...
  break;
default:
  assert(INVALID_SWITCH_VALUE);
}

Quando gestisci i vari stati di un enum (C #):

enum AccountType
{
    Savings,
    Checking,
    MoneyMarket
}

Quindi, all'interno della routine ...

switch (accountType)
{
    case AccountType.Checking:
        // do something

    case AccountType.Savings:
        // do something else

    case AccountType.MoneyMarket:
        // do some other thing

    default:
-->     Debug.Fail("Invalid account type.");
}

Ad un certo punto aggiungerò un altro tipo di account a questa enum. E quando lo farò, dimenticherò di correggere questa istruzione switch. Quindi gli Debug.Failarresti anomali (in modalità Debug) attirano la mia attenzione su questo fatto. Quando aggiungo case AccountType.MyNewAccountType:, l'orribile arresto si interrompe ... fino a quando non aggiungo un altro tipo di account e dimentico di aggiornare i casi qui.

(Sì, il polimorfismo è probabilmente meglio qui, ma questo è solo un esempio dalla parte superiore della mia testa.)

Quando stampo messaggi di errore con una stringa (in particolare uno che dipende dall'input dell'utente), utilizzo sempre virgolette singole ''. Per esempio:

FILE *fp = fopen(filename, "r");
if(fp == NULL) {
    fprintf(stderr, "ERROR: Could not open file %s\n", filename);
    return false;
}

Questa mancanza di virgolette %sè davvero negativa, perché dire il nome del file è una stringa vuota o solo uno spazio bianco o qualcosa del genere. Il messaggio stampato sarebbe ovviamente:

ERROR: Could not open file

Quindi, sempre meglio fare:

fprintf(stderr, "ERROR: Could not open file '%s'\n", filename);

Quindi almeno l'utente vede questo:

ERROR: Could not open file ''

Trovo che ciò faccia un'enorme differenza in termini di qualità delle segnalazioni di bug inviate dagli utenti finali. Se c'è un messaggio di errore dall'aspetto divertente come questo invece di qualcosa di generico, allora è molto più probabile che lo copi / incolli invece di scrivere semplicemente "non aprire i miei file".

Sicurezza SQL

Prima di scrivere qualsiasi SQL che modificherà i dati, avvolgo il tutto in una transazione rollback:

BEGIN TRANSACTION
-- LOTS OF SCARY SQL HERE LIKE
-- DELETE FROM ORDER INNER JOIN SUBSCRIBER ON ORDER.SUBSCRIBER_ID = SUBSCRIBER.ID
ROLLBACK TRANSACTION

Questo ti impedisce di eseguire definitivamente una cancellazione / aggiornamento errato. Inoltre, puoi eseguire tutto e verificare conteggi ragionevoli dei record o aggiungere SELECTistruzioni tra il tuo SQL e il ROLLBACK TRANSACTIONper assicurarti che tutto appaia corretto.

Quando sei completamente sicuro che fa quello che ti aspettavi, cambia ROLLBACKin COMMITe corri per davvero.

Per tutte le lingue:

Ridurre l'ambito delle variabili al minimo possibile. Evita le variabili che sono appena fornite per portarle nella dichiarazione successiva. Le variabili che non esistono sono variabili che non è necessario comprendere e di cui non si può essere ritenuti responsabili. Usa Lambdas quando possibile per lo stesso motivo.

In caso di dubbio, bombardare l'applicazione!

Controlla ogni singolo parametro all'inizio di ogni singolo metodo (sia che tu lo codifichi esplicitamente da solo, o utilizzando la programmazione basata su contratto non contenga qui) e bombarda con l'eccezione corretta e / o un messaggio di errore significativo se qualsiasi condizione preliminare al codice è non soddisfatti.

Conosciamo tutti questi presupposti impliciti quando scriviamo il codice , ma se non vengono controllati esplicitamente, creiamo labirinti per noi stessi quando qualcosa va storto in seguito e pile di dozzine di chiamate di metodo separano l'occorrenza del sintomo e l'ubicazione effettiva dove non è soddisfatta una condizione preliminare (= dove si trova effettivamente il problema / bug).

In Java, in particolare con le raccolte, utilizzare l'API, quindi se il metodo restituisce il tipo Elenco (ad esempio), provare quanto segue:

public List<T> getList() {
    return Collections.unmodifiableList(list);
}

Non permettere a nulla di sfuggire alla tua classe che non è necessario!

in Perl, lo fanno tutti

use warnings;

mi piace

use warnings FATAL => 'all';

Ciò causa la morte del codice per qualsiasi avviso di compilatore / runtime. Questo è utile soprattutto per catturare stringhe non inizializzate.

use warnings FATAL => 'all';
...
my $string = getStringVal(); # something bad happens;  returns 'undef'
print $string . "\n";        # code dies here

C #:

string myString = null;

if (myString.Equals("someValue")) // NullReferenceException...
{

}

if ("someValue".Equals(myString)) // Just false...
{

}

Nel controllo c # di string.IsNullOrEmpty prima di eseguire qualsiasi operazione sulla stringa come lunghezza, indexOf, metà ecc

public void SomeMethod(string myString)
{
   if(!string.IsNullOrEmpty(myString)) // same as myString != null && myString != string.Empty
   {                                   // Also implies that myString.Length == 0
     //Do something with string
   }
}

[Modifica]
Ora posso anche fare quanto segue in .NET 4.0, che controlla inoltre se il valore è solo uno spazio

string.IsNullOrWhiteSpace(myString)

In Java e C #, assegna a ogni thread un nome significativo. Ciò include i thread del pool di thread. Rende i dump dello stack molto più significativi. Ci vuole un po 'più di sforzo per dare un nome significativo anche ai thread del pool di thread, ma se un pool di thread ha un problema in un'applicazione a esecuzione prolungata, posso causare un dump dello stack (sai di SendSignal.exe , giusto? ), afferrare i log e senza dover interrompere un sistema in esecuzione posso dire quali thread sono ... qualunque cosa. Impasse, perdite, crescita, qualunque sia il problema.

Con VB.NET, l'opzione Opzione esplicita e Opzione rigorosa sono attivate per impostazione predefinita per l'intero Visual Studio.

C ++

#define SAFE_DELETE(pPtr)   { delete pPtr; pPtr = NULL; }
#define SAFE_DELETE_ARRAY(pPtr) { delete [] pPtr; pPtr = NULL }

quindi sostituisci tutte le chiamate " delete pPtr " e " delete [] pPtr " con SAFE_DELETE (pPtr) e SAFE_DELETE_ARRAY (pPtr)

Ora per errore se si utilizza il puntatore 'pPtr' dopo averlo eliminato, si otterrà l'errore di 'violazione dell'accesso'. È molto più facile da correggere rispetto ai danni alla memoria casuali.

Con Java, può essere utile utilizzare la parola chiave assert, anche se si esegue il codice di produzione con le asserzioni disattivate:

private Object someHelperFunction(Object param)
{
    assert param != null : "Param must be set by the client";

    return blahBlah(param);
}

Anche con asserzioni disattivate, almeno il codice documenta il fatto che param dovrebbe essere impostato da qualche parte. Si noti che questa è una funzione di supporto privata e non un membro di un'API pubblica. Questo metodo può essere chiamato solo da te, quindi è OK fare alcune ipotesi su come verrà utilizzato. Per i metodi pubblici, probabilmente è meglio gettare una vera eccezione per input non validi.

Non ho trovato la readonlyparola chiave fino a quando non ho trovato ReSharper, ma ora la utilizzo istintivamente, soprattutto per le classi di servizio.

readonly var prodSVC = new ProductService();

In Java, quando succede qualcosa e non so perché, a volte userò Log4J in questo modo:

if (some bad condition) {
    log.error("a bad thing happened", new Exception("Let's see how we got here"));
}

in questo modo ottengo una traccia dello stack che mi mostra come sono entrato in una situazione inaspettata, ad esempio un lucchetto che non è mai stato sbloccato, qualcosa di nullo che non può essere nullo e così via. Ovviamente, se viene generata una vera eccezione, non ho bisogno di farlo. Questo è quando ho bisogno di vedere cosa sta succedendo nel codice di produzione senza effettivamente disturbare nient'altro. Io non voglio gettare un'eccezione e non ho capito una. Voglio solo una traccia dello stack registrata con un messaggio appropriato per segnalarmi ciò che sta accadendo.

Se si utilizza Visual C ++, utilizzare la parola chiave override ogni volta che si supera il metodo di una classe base. In questo modo, se qualcuno dovesse mai cambiare la firma della classe base, genererà un errore del compilatore anziché il metodo errato che viene chiamato in silenzio. Questo mi avrebbe salvato alcune volte se fosse esistito prima.

Esempio:

class Foo
{
   virtual void DoSomething();
}

class Bar: public Foo
{
   void DoSomething() override { /* do something */ }
}

In Java ho imparato a non aspettare quasi mai all'infinito che un blocco si sblocchi, a meno che non mi aspetti davvero che potrebbe richiedere un tempo indefinitamente lungo. Se realisticamente, il blocco dovrebbe sbloccarsi in pochi secondi, quindi aspetterò solo per un certo periodo di tempo. Se il blocco non si sblocca, allora mi lamento e scarico stack nei registri e, a seconda di ciò che è meglio per la stabilità del sistema, o continuare come se il blocco fosse sbloccato o continuare come se il blocco non si fosse mai sbloccato.

Ciò ha contribuito a isolare alcune condizioni di gara e pseudo-deadlock che erano misteriose prima che iniziassi a farlo.

C #

• Verificare i valori non nulli per i parametri del tipo di riferimento nel metodo pubblico.
• Uso sealedmolto le lezioni per evitare di introdurre dipendenze dove non le volevo. Consentire l'eredità dovrebbe essere fatto esplicitamente e non per caso.

Quando si emette un messaggio di errore, almeno provare a fornire le stesse informazioni del programma quando ha preso la decisione di lanciare un errore.

"Autorizzazione negata" indica che si è verificato un problema di autorizzazione, ma non hai idea del perché o del luogo in cui si è verificato il problema. "Impossibile scrivere il registro delle transazioni / mio / file: filesystem di sola lettura" ti consente almeno di conoscere la base su cui è stata presa la decisione, anche se è sbagliata, soprattutto se è sbagliata: nome del file errato? aperto male? altro errore imprevisto? - e ti fa sapere dove ti trovavi quando hai avuto il problema.

In C #, usa la asparola chiave per trasmettere.

string a = (string)obj

genererà un'eccezione se obj non è una stringa

string a = obj as string

lascerà un as null se obj non è una stringa

È comunque necessario prendere in considerazione null, ma in genere è più semplice rispetto alla ricerca di eccezioni di cast. A volte si desidera un comportamento di tipo "cast o blow up", nel qual caso (string)objsi preferisce la sintassi.

Nel mio codice, trovo che uso la assintassi circa il 75% delle volte e la (cast)sintassi circa il 25%.

Preparati a qualsiasi input e qualsiasi input che ricevi sia inaspettato, scarica nei log. (Entro limiti ragionevoli. Se stai leggendo le password dell'utente, non scaricarle nei registri! E non registrare migliaia di questi tipi di messaggi nei registri al secondo. Motivo del contenuto, della probabilità e della frequenza prima di registrarlo .)

Non sto solo parlando della convalida dell'input dell'utente. Ad esempio, se stai leggendo richieste HTTP che prevedi di contenere XML, preparati per altri formati di dati. Sono stato sorpreso di vedere le risposte HTML dove mi aspettavo solo XML - fino a quando non ho visto e visto che la mia richiesta stava attraversando un proxy trasparente di cui non ero a conoscenza e che il cliente ha affermato di ignorare - e il proxy è scaduto nel tentativo di completare il richiesta. Quindi il proxy ha restituito una pagina di errore HTML al mio client, confondendo il diavolo dal client che si aspettava solo dati XML.

Pertanto, anche quando pensi di controllare entrambe le estremità del filo, puoi ottenere formati di dati imprevisti senza che sia coinvolto alcun malvagio. Preparati, codifica in modo difensivo e fornisci un output diagnostico in caso di input imprevisto.

Cerco di usare l'approccio Design by Contract. Può essere emulato il tempo di esecuzione in qualsiasi lingua. Ogni lingua supporta "assert", ma è facile e conveniente scrivere un'implementazione migliore che ti consenta di gestire l'errore in un modo più utile.

Nei 25 errori di programmazione più pericolosi, la "Convalida errata degli input" è l'errore più pericoloso nella sezione "Interazione insicura tra componenti".

L'aggiunta di asserzioni preliminari all'inizio dei metodi è un buon modo per assicurarsi che i parametri siano coerenti. Alla fine dei metodi scrivo postcondizioni , che controllano che l'output sia ciò che si intende essere.

Per implementare gli invarianti , scrivo un metodo in qualsiasi classe che controlla la "coerenza delle classi", che dovrebbe essere chiamato automaticamente dalla macro precondizione e postcondizione.

Sto valutando la libreria dei contratti di codice .

Giava

Java Java non ha alcun concetto di oggetti immutabili, il che è male! Final può aiutarti in quel caso. Contrassegna ogni classe immutabile con final e prepara la classe di conseguenza .

A volte è utile usare final sulle variabili locali per assicurarsi che non cambino mai il loro valore. L'ho trovato utile in costrutti loop brutti, ma necessari. È troppo facile riutilizzare accidentalmente una variabile anche se può essere una costante.

Usa la copia di difesa nei tuoi getter. A meno che non si restituisca un tipo primitivo o un oggetto immutabile, assicurarsi di copiare l'oggetto per non violare l'incapsulamento.

Non usare mai clone, usare un costruttore di copie .

Scopri il contratto tra equals e hashCode. Questo è violato così spesso. Il problema è che non influisce sul codice nel 99% dei casi. Le persone sovrascrivono sono uguali, ma non importa dell'hashCode. Esistono casi in cui il codice può rompersi o comportarsi in modo strano, ad esempio utilizzare oggetti mutabili come chiavi in ​​una mappa.

Ho dimenticato di scrivere echoin PHP troppe volte:

<td><?php $foo->bar->baz(); ?></td>
<!-- should have been -->
<td><?php echo $foo->bar->baz(); ?></td>

Mi ci vorrebbe un'eternità per provare a capire perché -> baz () non stava restituendo nulla quando in realtà non l'ho fatto eco! : -S Così ho creato una EchoMeclasse che potrebbe essere racchiusa in qualsiasi valore che dovrebbe essere ripetuto:

<?php
class EchoMe {
  private $str;
  private $printed = false;
  function __construct($value) {
    $this->str = strval($value);
  }
  function __toString() {
    $this->printed = true;
    return $this->str;
  }
  function __destruct() {
    if($this->printed !== true)
      throw new Exception("String '$this->str' was never printed");
  }
}

E poi per l'ambiente di sviluppo, ho usato un EchoMe per avvolgere le cose che dovrebbero essere stampate:

function baz() {
  $value = [...calculations...]
  if(DEBUG)
    return EchoMe($value);
  return $value;
}

Usando quella tecnica, il primo esempio mancante echoora genererebbe un'eccezione ...

C ++

Quando digito new, devo immediatamente digitare delete. Soprattutto per gli array.

C #

Controllare null prima di accedere alle proprietà, specialmente quando si utilizza il modello Mediatore. Gli oggetti vengono passati (e quindi devono essere lanciati usando as, come è già stato notato), quindi controllare con un valore null. Anche se pensi che non sarà nullo, controlla comunque. Sono stato sorpreso

Utilizzare un sistema di registrazione che consenta regolazioni dinamiche del livello di registro del tempo di esecuzione. Spesso se si deve interrompere un programma per abilitare la registrazione, si perde lo stato raro in cui si è verificato il bug. È necessario essere in grado di attivare ulteriori informazioni di registrazione senza interrompere il processo.

Inoltre, 'strace -p [pid]' su Linux mostrerà che vuoi che vengano fatte delle chiamate di sistema (o thread di Linux). All'inizio può sembrare strano, ma una volta che ti sarai abituato a ciò che le chiamate di sistema vengono generalmente fatte da ciò che libc chiama, lo troverai prezioso nella diagnosi sul campo.