¿Cuál es el propósito de un bloque 'if (0)' en el bloque if-else?

Mi pregunta es sobre la línea que he mencionado en el tema y que puedo ver en muchos lugares dentro del código de producción.

El código general se ve así:

if (0) {
    // Empty braces
} else if (some_fn_call()) {
    // actual code
} else if (some_other_fn_call()) {
    // another actual code
    ...
} else {
    // default case
}

Las otras ramas son irrelevantes para mi pregunta. Me pregunto cuál es el significado de poner if (0)aquí. Las llaves están vacías, así que no creo que deba comentar algún bloque de código. ¿Obliga al compilador a hacer alguna optimización o sus intenciones son diferentes?

He intentado buscar este caso explícito aquí en SO y en Internet, pero sin éxito. Hay preguntas similares sobre JavaScript, pero no C. Hay otra pregunta, ¿qué sucede cuando se asigna un cero en una condición `if`? , pero analiza la asignación cero a una variable, no el uso 'if (0)' en sí mismo.

A veces uso esto para la simetría para poder mover el otro else if{libremente con mi editor sin tener que preocuparme por el primero if.

Semánticamente el

if (0) {
    // Empty braces
} else 

parte no hace nada y puede contar con optimizadores para eliminarlo.

Esto puede ser útil si hay #ifdeclaraciones, ala

   if (0)
   {
       // Empty block
   }
#if TEST1_ENABLED
   else if (test1())
   {
      action1();
   }
#endif
#if TEST2_ENABLED
   else if (test2())
   {
      action2();
   }
#endif

etc.

En este caso, cualquiera (y todas) de las pruebas se pueden #ifeliminar y el código se compilará correctamente. Casi todos los compiladores eliminarán la if (0) {}pieza. Un generador automático simple podría generar un código como este, ya que es un poco más fácil de codificar: no tiene que considerar el primer bloque habilitado por separado.

He visto un patrón similar usado en el código generado. Por ejemplo, en SQL, he visto que las bibliotecas emiten la siguiente wherecláusula.

where 1 = 1

Presumiblemente, esto hace que sea más fácil agregar otros criterios, ya que todos los criterios adicionales pueden anteponerse en andlugar de una verificación adicional para ver si es el primer criterio o no.

Tal como está escrito, el if (0) {} cláusula se compila en nada.

Sospecho que la función de la cláusula en la parte superior de esta escalera es proporcionar un lugar fácil para deshabilitar temporalmente todas las demás funciones a la vez (para fines de depuración o comparación) cambiando el 0a a 1o true.

No estoy seguro de ninguna optimización, pero mis dos centavos:

Esto sucedió debido a alguna modificación del código, donde se eliminó una condición primaria (la llamada a la función en el ifbloque inicial , digamos), pero los desarrolladores / mantenedores

• fueron perezosos para reestructurar elif-else bloque
• no quería bajar en el recuento de cobertura de sucursales

así que en lugar de eliminar el ifbloque asociado , simplemente cambiaron la condición if(0)y continuaron.

Es la putrefacción del código.

En algún momento que "si" hizo algo útil, la situación cambió, tal vez se eliminó la variable que se está evaluando.

La persona que estaba arreglando / cambiando el sistema hizo lo menos posible para afectar la lógica del sistema por lo que se aseguró de que el código se volviera a compilar. Entonces deja un "si (0)" porque es rápido y fácil y no está totalmente seguro de que eso es lo que quiere hacer. Hace que el sistema funcione y no regresa para arreglarlo por completo.

Luego aparece el siguiente desarrollador y piensa que se hizo deliberadamente y solo comenta esa parte del código (ya que de todos modos no se está evaluando), luego la próxima vez que se toque el código, esos comentarios se eliminarán.

Una posibilidad aún no mencionada: la if (0) {línea podría ser un lugar conveniente para un punto de interrupción.

La depuración a menudo se realiza en código no optimizado, por lo que la prueba siempre falsa estará presente y podrá tener un punto de interrupción establecido. Cuando se compila para la producción, la línea de código se optimizará. La línea aparentemente inútil brinda funcionalidad para el desarrollo y las versiones de prueba sin afectar las versiones de lanzamiento.

Hay otras buenas sugerencias anteriores también; La única forma de saber realmente cuál es el propósito es localizar al autor y preguntar. Su sistema de control de código fuente podría ayudar con eso. (Busque la blamefuncionalidad de tipo).

He visto bloques de código no accesibles en JavaScript previamente expandido que se han generado utilizando un lenguaje de plantillas.

Por ejemplo, el código que está leyendo podría haberse pegado desde un servidor que evaluó previamente la primera condición que en ese momento dependía de una variable solo disponible en el lado del servidor.

if ( ${requestIsNotHttps} ){ ... }else if( ...

que una vez compilaron previamente hences:

if ( 0 ){ ... }else if ( ...

¡Espero que esto te ayude a relativizar la potencial actividad de teclado bajo de la era de los codificadores de reciclaje profesional por la cual manifesté entusiasmo!

Esa construcción también se puede usar en C para implementar programación genérica con seguridad de tipo, basándose en el hecho de que el compilador sigue comprobando el código inalcanzable:

// this is a generic unsafe function, that will call fun(arg) at a later time
void defer(void *fun, void *arg);

// this is a macro that makes it safer, by checking the argument
// matches the function signature
#define DEFER(f, arg) \
   if(0) f(arg); \              // never actually called, but compile-time checked
   else defer(f, (void *)arg);  // do the unsafe call after safety check

void myfunction(int *p);

DEFER(myfunction, 42);     // compile error
int *b;
DEFER(myfunction, b);      // compiles OK

Creo que es solo un mal código. Al escribir un ejemplo rápido en Compiler Explorer, vemos que tanto en gcc como en clang no se genera código para elif (0) bloque, incluso con optimizaciones completamente deshabilitadas:

https://godbolt.org/z/PETIks

Jugar con la eliminación de las if (0)causas no causa cambios en el código generado, por lo que concluyo que esto no es una optimización.

Es posible que haya algo en el ifbloque superior que luego se eliminó. En resumen, parece que eliminarlo podría generar exactamente el mismo código, así que siéntase libre de hacerlo.

Como se ha dicho, el cero se evalúa como falso y es probable que el compilador optimice la rama.

También he visto esto antes en el código donde se agregó una nueva función y se necesitaba un interruptor de apagado (si algo sale mal con la función, simplemente puede desactivarlo), y algún tiempo después, cuando se quitó el interruptor de apagado el programador tampoco eliminó la rama, por ejemplo

if (feature_a_active()) {
    use_feature_a();
} else if (some_fn()) {
   ...

convirtió

if (0) {
   // empty
} else if (some_fn()) {
   ...

Ayuda a depurar este bloque simplemente colocando el bloque 1. Esto deshabilita toda la funcionalidad del bloque if else. Y también podemos expandir el bloque if else.

    Actually according to my opinion, if we put any variable for checking inside
    e.g:-
public static void main(string args[])
{
        var status;
        var empList=_unitofWork.EmpRepository.Get(con=>con.isRetired==true);
        //some code logic 
        if(empList.count>0)
        {
          status=true;
        }
        if(status)
        {
         //do something
        }
        else
        {
        //do something else
        }
}
     if then its dynamically get the value in run time and invoke the logic inside it, else its simply extra line of code i guess.

    Anybody have any depth knowledge why this thing is used....or agree with me.
    kindly respond. 

La respuesta de @ PSkocik está bien, pero agrego mis dos centavos. No estoy seguro si debo hacer esto como un comentario, o como una respuesta; elegir este último, porque en mi humilde opinión vale la pena ver a otros, mientras que los comentarios son con frecuencia invisibles.

No solo uso ocasionalmente

if(0) {
   //deliberately left empty
} else if( cond1 ) {
   //deliberately left empty
} else if( cond2 ) {
   //deliberately left empty
...
} else {
   // no conditions matched
}

Pero también ocasionalmente

if( 1 
    && cond1 
    && cond2
    ...
    && condN
) {

o

if( 0 
    || cond1 
    || cond2
    ...
    || condN
) {

para condiciones complicadas Por las mismas razones: más fácil de editar, #ifdef, etc.

Para el caso, en Perl haré

@array = (  
    elem1,
    elem2,
    ...
    elem1,
) {

• tenga en cuenta la coma al final de la lista. Olvidé si las comas son separadores o delimitadores en las listas C y C ++. En mi humilde opinión, esto es algo que hemos aprendido: [ ¿Las comas finales en Perl son una mala práctica? las comas] son ​​algo bueno. Como cualquier nueva notación, lleva un tiempo acostumbrarse.

Comparo el if(0)código con lisp

(cond   (test1    action1)
   (test2    action2)
   ...
   (testn   actionn))

que, lo has adivinado, puedo sangrar como

(cond   
   (test1    action1)
   (test2    action2)
   ...
   (testn   actionn)
)

A veces he tratado de imaginar cómo podría ser una sintaxis más legible para esto.

Quizás

IF
:: cond1 THEN code1
:: cond2 THEN code2
...
:: condN THEN codeN
FI

inspirado por Dikstra [ https://en.wikipedia.org/wiki/Guarded_Command_Language#Selection:_if[[Guarded Command Language].

Pero esta sintaxis implica que las condiciones se evalúan en paralelo, mientras que if...else-ifimplica una evaluación secuencial y priorizada de las condiciones.

Comencé a hacer este tipo de cosas cuando escribía programas que generaban otros programas, donde es especialmente conveniente.

Mientras estamos en eso, cuando escribo RTL usando el viejo iHDL de Intel, he codificado cosas como

   IF 0 THEN /*nothing*/
   **FORC i FROM 1 TO 10 DOC** 
   ELSE IF signal%i% THEN    
      // stuff to do if signal%i% is active
   **ENDC** 
   ELSE   
      // nothing matched 
   ENDIF

donde FORC..DOC..ENDCes una construcción de bucle de preprocesador de macro, que se expande a

   IF 0 THEN /*nothing*/
   ELSE IF signal1 THEN    
      // stuff to do if signal1 is active
   ELSE IF signal2 THEN    
      // stuff to do if signal2 is active
   ...
   ELSE IF signal100 THEN    
      // stuff to do if signal100 is active
   ELSE   
      // nothing matched 
   ENDIF

Este era un código de asignación única, no imperativo, por lo que no se permitía establecer una variable de estado, si necesitaba hacer cosas como encontrar el primer bit establecido.

   IF 0 THEN /*nothing*/
   ELSE IF signal1 THEN    
      found := 1
   ELSE IF signal2 THEN    
      found := 2
   ...
   ELSE IF signal100 THEN    
      found := 100
   ELSE   
      // nothing matched 
   ENDIF

Ahora que lo pienso, este puede haber sido el primer lugar en el que me encontré con tales construcciones.

Por cierto, las objeciones que algunos tenían al estilo if (0), que las condiciones else-if dependen secuencialmente y no se pueden reordenar arbitrariamente, no se aplican a la lógica AND y OR y XOR en RTL, pero se aplican a short- circuito && y ||.

He visto esto usado para manejar errores, por ejemplo

if(0){
lable1:
   //do something
}
if(0){
lable2:
   //do something
}
.
.
and so on.

if(condition_fails)
   goto lable1;

Esto puede ser útil cuando goto se usa para administrar errores, las declaraciones se ejecutan solo cuando ocurre un error. Vi esto en un código C muy antiguo (donde los argumentos de la función están escritos fuera de '()'), no creo que nadie siga esto ahora.

Lo he visto varias veces, creo que la razón más probable es que estaba evaluando algo en una versión / rama más antigua / diferente del código, o posiblemente para la depuración, y cambiarlo a if(0)es una forma algo perezosa de eliminar lo que estaba allí .