Hai una lista di ricerca / sostituzione di miglioramenti al codice C / C ++ che non causa effetti collaterali?

Naviga le tue risposte
0

Di volta in volta devi lavorare con codice che non è sicuro come vorresti che fosse. O quello è qualcun altro codice, o qualcosa che hai scritto alle 3 di 5 anni fa, ma succede.

E in quei casi sarebbe bello rendere quel codice un po 'più sicuro e più incline agli errori di battitura.

Allo stesso tempo, vuoi evitare test approfonditi, e se il codice non è coperto da test unitari, beh, siamo onesti, anche se lo fosse, non puoi essere sicuro di non rompere nulla quando facendo la maggior parte delle cose di refactoring.

Quindi, quello che mi chiedo è, quale sarebbe una lista per il codice C / C ++ che può essere automatizzato per quasi "trovare / sostituire tutto" che renderebbe il codice più sicuro, senza avere il rischio elevato di modificare il comportamento dei programmi .

Poche cose mi sono venute in mente:

  • Rendi const tutte le funzioni membro
  • Crea tutti gli argomenti per le funzioni collegate internamente const
  • Rimuovi tutti i cast di stile C e sostituiscili con gli stili C ++ sugli errori
  • Trasforma la maggior parte delle macro in funzioni o modelli inline
  • modifica l'enumerazione delle enumerazioni digitate

Ma la maggior parte di loro avrebbe bisogno di una ricompilazione e verifiche manuali. Hai altri candidati e forse anche più sicuri?

    
posta Coder 14.12.2011 - 19:07
fonte

3 risposte

7

Personalmente direi che non esiste una tale lista.

Ci sono molti tipi di sintassi che hanno alcuni "equivalenti più sicuri" ma per i quali ci sono troppi motivi giustificabili da usare per dire che dovrebbe essere sostituito con il codice "più sicuro".

Ad esempio, non tutte le funzioni membro dovrebbero essere const , e ci sono casi in cui non si vuole fare una cosa del genere. Ci sono buone ragioni per non rendere parametri alle funzioni const , così come ci sono dei motivi per renderli const . Vi sono casi in cui una macro simile a una funzione è in realtà una macro che genera il codice o in cui non è giustificata la sua trasformazione in una funzione in linea. Potrebbero esserci motivi per preferire un "normale" enum su un% dattilografato% _.

Non ci sono abbastanza regole rigide, credo, per prendere in considerazione anche i candidati.

Ci sono alcune regole generali: Preferisci riferimenti su puntatori; evitare l'uso di enum quando possibile; evitare di scrivere new overload; e così via. Ma ci sono delle eccezioni a tutte queste "regole" e ci sono degli argomenti per ignorarle.

La maggior parte di questo è una questione di stile. Usa qualsiasi stile appropriato.

    
risposta data 14.12.2011 - 19:42
fonte
2

Aritmetica del puntatore, nel caso generale. Non tutto l'aritmetica dei puntatori è cattiva, ma la stragrande maggioranza dovrebbe essere ben incapsulata e mai mostrata all'utente. Segnalerei anche le chiamate a new e delete come degne di un secondo sguardo.

    
risposta data 14.12.2011 - 19:18
fonte
1
  • correggi tutti gli avvisi
  • compilare con il livello di avviso massimo
  • rimuovi tutti i cast di stile c
  • rimuovi tutte le macro non necessarie
  • cerca di ottenere una copertura del 100% del codice con buoni test unitari e qualità del codice
risposta data 14.12.2011 - 21:09
fonte

Leggi altre domande sui tag

Come posso aiutare un membro del team ad essere più sicuro? Applicazione di commit in un altro ramo senza unione