Tecniche di programmazione difensive [chiuso]

7

Stavo tentando di identificare un elemento dell'ingegneria del software che ritengo trascurato, non enfatizzato o non insegnato nel tipico corso di laurea per CS o SE. Quello che mi è venuto in mente è il concetto di programmazione difensiva. Mi piacerebbe sentire le opzioni della comunità sul programma difensivo e / o sulle tecniche specifiche che usi regolarmente. Inoltre, vorrei sapere se esistono tecniche specifiche per la lingua.

Modifica:

Solo per più chiaro. Non sto cercando una lezione sul programma difensivo. Capisco di cosa si tratta. Speravo che questo sarebbe stato più di discussione sui diversi metodi che i membri della comunità impiegano o trovano di valore. Ecco alcune tecniche che uso. Tieni presente che uso C quasi esclusivamente.

Standard di codifica. Inizialmente non si potrebbe pensare che questo abbia qualcosa a che fare con la programmazione difensiva, ma lo fa. Per illustrare, supponiamo che lo standard di codifica richieda di anteporre i nomi delle variabili al tipo di variabile come IntValue o UIntValue. La convenzione consente di individuare facilmente potenziali problemi delle regole di promozione come (IntX = IntValue * UIntValue)

Usa macro di preprocessore per le costanti. Personalmente, penso che questo renda il tuo programma più leggibile e mantenibile, ma fornisca anche una rete di sicurezza. Puoi essere sicuro che tutte le aree del codice che utilizzano la macro verranno aggiornate quando cambi il valore. Altri usi delle macro del preprocessore possono anche fornire attributi difensivi nel codice.

Alcune tecniche sono incorporate nel linguaggio come variabili statiche o dichiarazioni di funzioni o in incapsulamento di dati c ++.

Naturalmente ci sono quelli più ovvi tra cui la convalida di tutti i tuoi input e output.

    
posta Pemdas 02.01.2011 - 10:21
fonte

3 risposte

9

Dai un'occhiata a Codice completo 2 , capitolo 8: "Programmazione difensiva". Per me è stata la fonte migliore per questo tipo di tecnica finora. Piccolo (~ 30 pagine) e le idee principali sono lì.

Alcuni dei concetti principali sono stati copiati rigorosamente dal libro, con le mie parole (quindi, potrebbe essere meglio acquistare semplicemente il libro e leggere l'originale :-)):

  • Controlla e disinfetti i tuoi input;
  • Proteggi la tua routine dai cattivi dati. No "garbage in, garbage out";
  • Utilizza le asserzioni per documentare le condizioni preliminari e le condizioni post-vendita;
  • Standardizza la gestione delle eccezioni sul tuo codice;
  • Considera di non utilizzare eccezioni per tutto: puoi gestire gli errori in un altro modo, il mondo di programmazione esisteva prima che le eccezioni fossero inventate;
  • Il debug e le asserzioni ti aiutano durante lo sviluppo e la maggior parte (ma non tutte) delle debug / asserzioni devono essere disabilitate nel codice di produzione;

Ma per me, il concetto chiave si basa sulla fiducia o meno sul "altro" codice con cui stai lavorando.

    
risposta data 02.01.2011 - 15:30
fonte
6

Suppongo che non avrai mai troppe asserzioni nel tuo programma ... Aggiungi qualche invariante stretto alle tue classi, e prendi come garantito che qualunque riferimento / puntatore tu usi sarà essere nullo in uno tempo o altro ...

    
risposta data 02.01.2011 - 12:09
fonte
3

Molte parti della programmazione difensiva sono state incorporate nei programmi di apprendimento accettati. La programmazione difensiva comporta molte cose diverse, anche se ruotano tutte intorno alla "gestione dell'inaspettato". I linguaggi mainstream come Java e C # hanno esplicite 'eccezioni' e 'asserzioni' che provengono dalla filosofia di programmazione difensiva. Dovresti assolutamente usare le eccezioni nel tuo codice. Le asserzioni sono più di una programmazione difensiva "pura" e, non sottostando agli avvertimenti riportati di seguito, dovresti usarli con parsimonia (al di fuori del codice di test), ma se del caso.

Due altri aspetti della programmazione difensiva tradizionale sono ora gestiti con nomi diversi. Il primo è semplicemente 'Sicurezza'. Non entrerò in tutto ciò che riguarda la scrittura di codice sicuro qui.

Un altro è "Design by Contract". Questo metodo di programmazione è in uscita a causa dell'aumento di "Agile", in quanto è visto come un design troppo caricato in anticipo. Parte della ragione di ciò è duplice, in primo luogo, molte delle precedenti esigenze di imporre contratti nella programmazione imperativa sono ora gestite dalla gerarchia delle classi OOP in modo tale che è impossibile entrare nei cattivi stati, quindi non c'è bisogno di controllali. In secondo luogo, molte delle tradizionali necessità di controllare parametri come per buffer overflow, ora generano automaticamente eccezioni dal runtime e quindi non devono essere controllate dal coder (il runtime sta controllando). Infine, c'è un disco, in modo agile, verso lo sviluppo basato sui test, ed è talvolta impossibile generare test unitari per condizioni che non dovrebbero verificarsi. In questi casi, un codice difensivo causerà la riduzione della copertura del codice, che è una cosa negativa.

    
risposta data 02.01.2011 - 12:09
fonte

Leggi altre domande sui tag