¿Se usan banderas con mucha frecuencia en el código?

Question

me encontré con muchas banderas durante la lectura de código de alguien más,

if (condition1) 
    var1 = true 
else 
    var1 = false 

luego,

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

Hay muchas banderas de este tipo. Estoy ansioso por saber, ¿está usando banderas muy a menudo en el código aconsejable?

Answer 1

Este:

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

es un código clásico mal escrito.
En lugar usted debe escribir:

var1 = condition1; 

Y sí, banderas son muy útiles para hacer que el código sea más legible y, posiblemente, más rápido.

Answer 2

Esto es bastante subjetivo, y depende del resto del código. Las "banderas" como las llamas tienen su lugar.

Answer 3

Es aconsejable si condition1 es algo bastante complicado - como if (A && (B || C) && !D) o contiene una gran cantidad de gastos generales (if (somethingTimeConsumingThatWontChange())), entonces tiene sentido para almacenar ese resultado en lugar de copiar y pegar el código.

Si condition1 es simplemente una comparación, entonces no, no utilizaría una bandera.

Answer 4

En primer lugar, este código debe leer como esto:

var1 = condition1; 

if(var1) 

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

En cuanto al número de banderas, hay formas más elegantes de ramificación su código. Por ejemplo, cuando se utiliza javascript que puede hacer cosas como esta:

var methodName = someFunctionThatReturnsAString(); 

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

en lugar de

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

Si estás utilizando un lenguaje fuertemente tipado, el polimorfismo es su amigo. Creo que la técnica se refiere como despacho polimórfica

Answer 5

Recuerdo este Replace Temp var with Query method del libro de refactorización. Creo que esta refactorización hará que el código sea más legible, pero acepto que podría afectar el rendimiento cuando el método de consulta es costoso ... (Pero, tal vez el método de consulta puede colocarse en su propia clase, y el resultado puede ser guardado en caché en esa clase).

Answer 6

Esta es una pregunta un poco genérica. La respuesta depende de lo que quiere hacer y con qué idioma desea que lo haga. Suponiendo un contexto OO que podría haber mejores enfoques.

Si la condición es el resultado de algún estado del objeto, la "bandera" debería ser una propiedad del propio objeto. Si es una condición de la aplicación en ejecución y tiene muchas de estas cosas, podría ser que deba pensar en un patrón de estado/máquina de estado.

Answer 7

Si es legible y hace el trabajo, entonces no tiene nada de malo.Simplemente haga uso de "tiene" y "es" como prefijo para que sea más legible:

var $isNewRecord; 
var $hasUpdated; 

if ($isNewRecord) 
{ 
} 

if ($hasUpdated) 
{ 
} 

Answer 8

Eso depende de la condición y el número de veces que se utiliza. De todos modos, la refacturación en la función (preferiblemente el almacenamiento en caché del resultado si la condición es lenta para calcular) podría darte un código mucho más legible.

Considérese, por ejemplo, esto:

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

---

cuanto a estilo de codificación:

if (condition1) 
    var1= true 
else 
    var1 = false 

odio ese tipo de código. Debe quedar bien simple:

var1 = condition1 

o si se quiere asegurar que es resultado es booleano:

var1 = bool(condition1) 

---

si (var1 == true)

De nuevo . Mal estilo de codificación Es:

if (var1) 

Answer 9

Teniendo en cuenta que ese código se podría escribir más legible como

var1 = condition1 

, esta asignación tiene algunas propiedades útiles si se usan bien. Un caso de uso es nombrar un cálculo complicado sin romperlo a cabo en una función:

user_is_on_fire = condition_that_holds_when_user_is_on_fire 

Eso permite una para explicar lo que se está utilizando la condición en el sentido de que a menudo no es obvio a partir de la condición desnudo.

Si la evaluación de la condición es costosa (o tiene efectos secundarios), también podría ser conveniente almacenar el resultado localmente en lugar de reevaluar la condición.

Algunas advertencias: Las banderas mal llamadas tenderán a hacer que el código sea menos legible. Lo mismo ocurrirá con las banderas que están ubicadas lejos del lugar donde se usan. Además, el hecho de que uno quiera usar banderas es un olor codificado que sugiere que uno debería considerar romper la condición en una función.

lo marca

Answer 10

Call D'A cuando se trabaja en un lenguaje pre-OO. Son útiles para parametrizar el comportamiento de un fragmento de código.

Sin embargo, pronto encontrarás el código difícil de seguir. Sería más fácil leer/cambiar/mantener cuando abstrae las diferencias, por ej. proporcionando una referencia a la funcionalidad modificable.

En idiomas donde las funciones son citisens de primera clase (por ejemplo, Javascript, Haskell, Lisp, ...), esto es muy fácil.

En OO idiomas, puede implementar algunos patrones de diseño como Abstract Factory, Strategy/Policy, ...

Demasiados conmutadores que personalmente considero como códigos maliciosos.

Answer 11

Las banderas son muy útiles, pero déles nombres razonables, p. Ej. usando "Es" o similar en sus nombres.

Por ejemplo, comparar:

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

con:

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

Answer 12

Lo que no me gusta acerca de las marcas, es decir cuando se les llama banderas, sin comentario alguno.

por ejemplo

void foo(...){ 

    bool flag; 

    //begin some weird looking code 

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

atentan contra redeability código. Y el pobre tipo que tiene que leerlo meses/años después de que el programador original se haya ido, va a tener dificultades para tratar de entender cuál era originalmente su propósito.

Sin embargo, si la variable del indicador tiene un nombre representativo, entonces creo que están bien, siempre que se utilicen con prudencia (ver otras respuestas).

Answer 13

Sí, eso es solo un código tonto sin sentido.

puede simplificar todo lo que reduce a:

if (condition1) 
{ 
    // do something 
} 

Answer 14

Esta es mi opinión. de código que usan banderas:

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

muy sucio. El programador simplemente codifica en el orden que su mente le indique. Se acaba de agregar código en un lugar al azar para recordarse a sí mismo que es necesaria la limpieza después ... ¿Por qué no hizo esto:

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

Y, siguiendo el asesoramiento de Robert Martin (Código Limpio), puede refactorizar lógica en el método más significativo:

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

mucha Así, he visto y las porciones de código en la que las reglas simples, como anteriormente se podía seguir, sin embargo, la gente sigue añadiendo complicaciones y banderas para ninguna razón! Ahora, hay casos legítimos en los que podrían necesitarse banderas, pero en la mayoría de los casos son un estilo que los programadores llevan del pasado.