L'utilizzo di flag è molto spesso consigliato nel codice?

Question

mi sono imbattuto in molte bandiere durante la lettura del codice qualcun altro,

if (condition1) 
    var1 = true 
else 
    var1 = false 

poi,

if (var1 == true) 
    // do something. 

Ci sono molte bandiere come questo. Voglio sapere, usa le bandiere molto spesso in codice consigliabile?

Answer 1

questo:

if (condition1) 
    var1= true; 
else 
    var1 = false; 

è un codice scritto male classico.
Invece si dovrebbe scrivere:

var1 = condition1; 

E sì, le bandiere sono molto utili per rendere il codice più leggibile e, eventualmente, più veloce.

Answer 2

Questo è piuttosto soggettivo e dipende dal resto del codice. Le "bandiere" come le chiami hanno il loro posto.

Answer 3

E 'consigliabile se condition1 è qualcosa di molto complicato - come if (A && (B || C) && !D) o contiene un sacco di overhead (if (somethingTimeConsumingThatWontChange())) allora ha senso per memorizzare quel risultato, invece di incollare copia il codice.

Se condition1 è solo un semplice confronto, no, non utilizzerei una bandiera.

Answer 4

Prima di tutto, questo codice dovrebbe leggere in questo modo:

var1 = condition1; 

if(var1) 

// No need to compare *true* to *true* when you're looking for *true* 

Per quanto riguarda il numero di bandiere, ci sono modi più eleganti di ramificazione codice. Per esempio, quando si utilizza JavaScript si può fare cose come questa:

var methodName = someFunctionThatReturnsAString(); 

// assuming you name the method according to what's returned 
myObject[ methodName ](); 

invece di

if(someFunctionThatReturnsAString === 'myPreferedMethod'){ 
    myObject.myPreferedMethod(); 
}else{ 
    myObject.theOtherMethod(); 
} 

Se stai usando un linguaggio fortemente tipizzato, il polimorfismo è tuo amico. Credo che la tecnica si riferisce a come spedizione polimorfico

Answer 5

Ricordo questo Replace Temp var with Query method dal libro di refactoring. Penso che questo refactoring renderà il codice più leggibile, ma sono d'accordo che potrebbe influenzare le prestazioni quando il metodo di query è costoso ... (Ma forse il metodo di query può essere messo nella sua classe, e il risultato può essere memorizzato in quella classe).

Answer 6

Questa è una domanda un po 'generica. La risposta dipende da cosa vuoi fare e con quale lingua vuoi che faccia. Supponendo un contesto OO di quanto potrebbero esserci approcci migliori.

Se la condizione è il risultato di qualche stato dell'oggetto, la "bandiera" dovrebbe essere una proprietà dell'oggetto stesso. Se si tratta di una condizione dell'applicazione in esecuzione e si hanno molte di queste cose, potrebbe essere necessario pensare a una macchina di stato/modello di stato.

Answer 7

Se è leggibile e fa il lavoro allora non c'è niente di sbagliato in esso.Basta fare uso di "ha" e "si" prefisso per renderlo più leggibile:

var $isNewRecord; 
var $hasUpdated; 

if ($isNewRecord) 
{ 
} 

if ($hasUpdated) 
{ 
} 

Answer 8

Questo dipende dalle condizioni e quante volte viene utilizzato. In ogni caso, il refactoring in funzione (preferibilmente il caching del risultato se la condizione è lenta da calcolare) potrebbe fornire un codice molto più leggibile.

Consideriamo per esempio questo:

def checkCondition(): 
    import __builtin__ as cached 
    try: 
     return cached.conditionValue 
    except NameError: 
     cached.conditionValue = someSlowFunction() 
     return cached.conditionValue 

---

Per quanto riguarda la codifica stile:

if (condition1) 
    var1= true 
else 
    var1 = false 

odio quel tipo di codice. Dovrebbe essere o semplicemente:

var1 = condition1 

o se si vuole assicurare che è risultato è booleano:

var1 = bool(condition1) 

---

se (var1 == true)

Anche in questo caso . Cattivo stile di codifica E ':

if (var1) 

Answer 9

Tenendo presente che che il codice potrebbe essere più essere letti scritto come

var1 = condition1 

, questa assegnazione ha alcune proprietà utili se usato bene. Un caso d'uso è quella di nominare un calcolo complicato senza romperlo fuori in una funzione:

user_is_on_fire = condition_that_holds_when_user_is_on_fire 

che permette di spiegare ciò che si sta usando la condizione per significare, che spesso non è evidente dalla condizione nuda.

Se la valutazione della condizione è costosa (o ha effetti collaterali), potrebbe anche essere preferibile memorizzare il risultato localmente piuttosto che rivalutare la condizione.

Alcune avvertenze: le bandiere con un nome errato tendono a rendere il codice meno leggibile. Quindi i flag verranno posizionati lontano dal luogo in cui vengono utilizzati. Inoltre, il fatto che si voglia usare flag è un odore di codice che suggerisce che si dovrebbe prendere in considerazione la possibilità di rompere la condizione in una funzione.

D'A

Answer 10

Chiamatela bandiere quando si lavora in un linguaggio pre-OO. Sono utili per parametrizzare il comportamento di un pezzo di codice.

Troverete il codice difficile da seguire, presto, tuttavia. Sarebbe più semplice leggere/cambiare/mantenere quando estrai le differenze, ad es. fornendo un riferimento alla funzionalità mutevole.

Nelle lingue in cui le funzioni sono citisens di prima classe (ad esempio Javascript, Haskell, Lisp, ...), questo è un gioco da ragazzi.

In lingue OO, è possibile implementare alcuni modelli di progettazione come Fabbrica astratta, Strategia/Politica, ...

Troppi interruttori Personalmente considero l'odore del codice.

Answer 11

Le bandiere sono molto utili, ma date loro nomi ragionevoli, ad es. usando "È" o simili nei loro nomi.

Per esempio, confrontare:

if(Direction) {/* do something */} 
if(PowerSetting) {/* do something else */} 

con:

if(DirectionIsUp) {/* do something */} 
if(PowerIsOn)  {/* do something else */} 

Answer 12

Cosa non mi piace sui flag, è quando vengono chiamati bandiere, senza commenti di sorta.

es

void foo(...){ 

    bool flag; 

    //begin some weird looking code 

    if (something) 
     [...] 
     flag = true; 
} 

tentano contro il codice redeability. E il povero ragazzo che deve leggerlo mesi/anni dopo che il programmatore originale se n'è andato, avrà qualche difficoltà a cercare di capire quale sia stata la sua origine originale.

Tuttavia, se la variabile flag ha un nome rappresentativo, penso che siano ok, purché siano usati con saggezza (vedere le altre risposte).

Answer 13

Sì, questo è solo un codice sciocco insensato.

è possibile semplificare tutto ciò che fino a:

if (condition1) 
{ 
    // do something 
} 

Answer 14

Ecco il mio prendere. codice che utilizzano bandiere:

... 
if (dogIsBarking && smellsBad) { 
    cleanupNeeded = true; 
} 
doOtherStuff(); 
... many lines later 
if (cleanupNeeded) { 
    startCleanup(); 
} 
... 

Molto impuro. Il programmatore semplicemente capita di codice in qualsiasi ordine la sua mente gli dice. Ha appena aggiunto il codice in un posto a caso per ricordare a se stesso che la pulizia è necessaria in seguito ... Perché non ha fatto questo:

... 
doOtherStuff(); 
... many lines later 
if (dogIsBarking && smellsBad) { 
    startCleanup(); 
} 
... 

E, seguendo consigli da Robert Martin (codice pulito), in grado di refactoring logica in modo più significativo:

... 
doSomeStuff(); 
... many lines later 
if (dogTookADump()) { 
    startCleanup(); 
} 
... 
boolean dogTookADump() { 
    return (dogIsBarking && smellsBad); 
} 

sacco Così, ho visto e un sacco di codice in cui potrebbe essere seguita semplici regole come sopra, ma la gente continuare ad aggiungere complicazioni e bandiere per nessun motivo! Ora, ci sono casi legali in cui le bandiere potrebbero essere necessarie, ma per la maggior parte dei casi sono uno stile che i programmatori stanno trasferendo dal passato.