Utilizzo di bool / flag per governare il flusso del programma C ++

1

Mi trovo costantemente a creare flag all'interno del mio programma C ++, che vengono successivamente controllati per determinare se devo fare qualcosa, e onestamente mi sento un po '"hack-y" nonostante sia una soluzione semplice.

Ad esempio, supponiamo che abbia una funzione:

update_employee_salary(EmployeeList employees_to_update )

update_employee_salary :

  1. Si collega al database
  2. Iterato attraverso tutti i dipendenti in EmployeeList e ottiene il loro stato (retribuito o orario) e crea due distinti elenchi dei dipendenti (hourly_emp, salary_emp)
  3. Aggiorna il mio employee_data nella cache
  4. Scrive i dati dei dipendenti nel database

Se il dipendente è un dirigente, voglio generare avvisi / registri che gli stipendi Executive sono stati aggiornati.

Voglio anche assicurarmi che, se per qualche motivo, dopo aver letto dal database, non sono in grado di scrivere sul database, che eseguo il backup di tutto. Per questo motivo, non voglio generare la notifica fino a quando non garantisco che è stata scritta nel database, quindi creerò un flag bool elist_contains_execs che viene controllato dopo che il database è stato aggiornato per generare la notifica.

Mi trovo a fare cose del genere per situazioni di ogni genere, e mi sento disgustato ogni volta che lo faccio, ma spesso mi sembra meglio che iterare attraverso l'elenco una seconda volta per determinare se contiene dirigenti dopo l'aggiornamento del database.

Domanda: l'uso di flag in C ++ si sente hacky a qualcun altro? Oppure accettiamo semplicemente che è spesso una soluzione semplice. Quali sono gli aspetti negativi dell'uso delle bandiere. Ad esempio, può rendere il codice più difficile da mantenere.

    
posta Triplell89 04.09.2015 - 22:49
fonte

1 risposta

3

Sembra che queste "bandiere" siano quelle che chiameremmo "variabili globali", le variabili dichiarate al massimo livello possibile in modo che possano essere lette e scritte da qualsiasi parte del programma.

Il problema con i globals è, naturalmente, che possono essere letti e scritti da ovunque , che in pratica significa che qualsiasi parte di codice che tocchi un globale è impossibile (pienamente) capire senza cercando ogni altro pezzo di codice che tocca lo stesso globale. Questo è davvero un classico mal di testa di manutenzione. I Globali dovrebbero sempre essere un'opzione di ultima istanza, usata solo quando sei sicuro che ogni alternativa sarebbe in qualche modo peggiore.

Per l'esempio specifico che hai fornito, la prima alternativa che mi viene in mente è un semplice parametro di output:

bool execUpdated = false;
int rcode = update_employee_salary(employees_to_update, &execUpdated);
if(rcode != 0) {
  // handle the error
} else {
  // handle the success
  if(execUpdated) {
     // show your notification
  }
}

Ora chiunque veda update_employee_salary sarà immediatamente a conoscenza di questo controllo speciale per gli aggiornamenti esecutivi, ed è impossibile "interrompere" questa funzione "dall'esterno" avendo un altro codice che manipola i globals sbagliati nel momento sbagliato .

    
risposta data 04.09.2015 - 23:16
fonte

Leggi altre domande sui tag