Si se llama a una función, y que funciones devuelve NULL en caso de error (piense en malloc() o fopen() por ejemplo), ¿cuál de los dos es mejor:Estilo pregunta condición agains condición == NULL
FILE *fp = fopen(argv[0], "r");
if (fp == NULL) {
// handle error
}
o
if (!fp) {
// handle error
}
¿es sólo una cuestión de estilo? Creo que el primero es más claro, más explícito, pero rara vez código en C :-).
Prefiero comparar con NULL, porque deja en claro que se supone que ambos operandos de la comparación son punteros. Este
(! P)
o esta
(p == 0)
requiere que usted sabe lo que es de tipo p (un entero? Un booleano?) De un vistazo. Soy de la opinión de que toda la codificación debe hacerse con la suposición de que tendrá que depurar la cosa a las 4 a. M. (Eso es las 4 de la mañana, para los insomnes) 9 meses después. En ese caso, todo ayuda.
Ah, y es una buena práctica colocar constantes como el primer operando cuando se prueba la igualdad, de modo que el compilador abortará con un error si accidentalmente lo convierte en una tarea.
Prefiero el primero en este caso, ya que está comparando explícitamente el valor para ver si es nulo (que pasa a ser 0).
El segundo dice que fp es un booleano, que no lo es.
Es como decir "¿Es este puntero inválido?" vs "¿Es este puntero falso?"
Cuál es más legible a que es, por supuesto, una cuestión de opinión.
Creo que esto es una cuestión de estilo. Personalmente, me gusta la segunda opción mejor. A otros les gusta el primero porque es más claro y más "apropiado". Algunas personas incluso escriben if (NULL == fp) para que nunca puedan olvidar accidentalmente un = y lo conviertan en una tarea. En general, creo que es una cuestión de gusto, y probablemente sea más importante ser un tanto coherente.
que no me gustan las condiciones de Yoda. Se siente como decir "Si el verde es el agua, ...". Además, mis compiladores me patean las tuercas para asignarlos en un condicional de todos modos. – dennycrane
En algunos casos, como éste: 'si (== SOME_CONST long_function_name (lotes, de, parámetros, con, largos, nombres)) {' poniendo constante en la parte delantera que no tienen que desplazarse para ver lo que son comparado a. (Odio usar nuevas líneas para los parámetros de función, por lo que prefiero este enfoque). – ruslik
Me encantan las "condiciones de Yoda" - finalmente una frase para esta estupidez :) ¡Gracias, Denny! – EboMike
¿Es solo una cuestión de estilo?
En el caso de C, que es sólo una cuestión de estilo que ambos son correctos, pero en general, creo que más gente (incluido yo) prefieren una comparación explícita (ptr == NULL) como lo demuestra el siguiente:
nullptr para enfatizar que es más que un mero número o valor booleano.obj == null) y no permite !obj.Prefiero "=="; Creo que el lector tiene que pensar menos.Esta es también la razón por la que detesto typedefs.
Sí, esto es cuestión de estilo. fp == NULL(perdón, me escribió fp = NULL ...) es muy clara y explícita en la que expresa, y es bueno para aquellos que no están familiarizados con todos los giros de C y vueltas. Altough !fp es muy parecido a un lenguaje y un juego de palabras: "No hay Hing en fp (!)". Ant es corto. Para esto me gusta !fp. Creo que a los diseñadores de C también les gusta esto, de lo contrario no deberían definir ! para los punteros. :)
Esto es lo que nunca tuve sobre todo el lugar-el-constante-on-the-LHS cosa: si puedo recordar a hacer eso, ¿No puedo recordar poner dos '' = símbolos? – jason
La mayoría de los compiladores advierten sobre tener una tarea en una condición, por lo que no es un gran problema, pero a veces es útil. – Kos
@Jason: la primera es una práctica que se sigue automáticamente, la segunda requiere que realmente tenga cuidado de presionar el = dos veces y que el editor capte la pulsación de tecla. Recuerde, a las 4 a. M. – thkala