resueltos - ¿Debo devolver los valores VERDADERO/FALSO de una función C?

funcion si

Question

Después de programar en C durante varios años, me di cuenta de que he estado ignorando la convención C de devolver cero de una función para indicar el éxito. La convención me parece semánticamente incorrecta, ya que cero es, por supuesto, falso. El problema es que me gusta nombrar funciones como is_valid_foobar() , y para acomodar la convención de ''falso significa éxito'', tendría que ser más vago ... es decir en vez de:

if ( ! is_valid_foobar() ) {
    return (error);
}

Otros programadores escriben:

if ( validate_foobar() ) {
     return (error);
}

Y mi implementación se ve así:

int is_valid_foobar (int foobar ) {
     if ( foobar < MAX_ALLOWED ) {
          return TRUE;
      }
      return FALSE;
}

En realidad, no he detectado ningún error en revisiones de código. Así que estoy pensando que no es un hábito tan terrible, pero es "poco convencional". Tengo curiosidad por lo que piensa la gente.

Soy muy cuidadoso con las elecciones que hago para la función y los nombres de variables, y un comentario típico de revisión es "el código es muy claro", ¡y además no me molesta en absoluto tener que escribir un extra ! al frente de la llamada de función. Pero ¿qué dices, oh poderosos de SO?

Answer 1

C no tiene ningún concepto de booleano que no sea 0 que sea falso, y que todo lo demás sea verdadero.

La idea de devolver 0 proviene de tener un código de retorno que indica cuál es la falla. Si no está haciendo un código de retorno, no hay nada de malo en considerar 1 y 0 como verdadero y falso. Después de todo, TRUE y FALSE son solo typedefs para 1 y 0 en C.

Sin embargo, esto debería estar bien documentado, y los comentarios de su función deberían indicar explícitamente "Devuelve VERDADERO o FALSO".

También podría escribir if (is_invalid_foobar ()), que podría hacer que la declaración sea fácil de entender y semánticamente correcta.

Answer 2

Especialmente cuando nombra su función is_foo (), las funciones estándar de caracteres C (isdigit (), isupper (), etc.) son un buen precedente para hacerlo a su manera.

Answer 3

Ha pasado un tiempo desde que programé C, pero creo que estás hablando de dos tipos de funciones diferentes aquí:

• is_foo es una función que busca alguna propiedad foo y devuelve 0 ( false ) o no 0 ( true ) para indicar el valor booleano de esa propiedad. Al llamar a esas funciones, no se espera ningún estado de error (y si sucede, se mapea en uno de esos valores).
• foo es una función que ejecuta la acción foo. Devuelve 0 en caso de éxito y un valor distinto de 0 en caso de error.

Answer 4

La convención no es exactamente lo que pareces pensar. Los procesos deben salir con un estado 0 para indicar el éxito, y las funciones que devuelven códigos de error a menudo usarán 0 para indicar "sin error". Pero como booleano, 0 debería significar falso y no cero significa verdadero. Utilizar 0 para boolean true lo pondrá en The Daily WTF algún día.

Answer 5

No es tanto una convención de C como un shell de UN * X. Considere las funciones Estándar C iasalpha (), isdigit () etc. Todos devuelven un valor distinto de cero para indicar el éxito. En pocas palabras: en C ''verdadero'' no es cero.

Answer 6

No estoy seguro de estar de acuerdo en que existe una convención de "devolver cero de una función para indicar el éxito".

AFAIK, la convención es que cero es falso, y todos los nonzeros son verdaderos en el caso de los predicados.

Sin embargo, esta convención solo debería aplicarse a predicados obvios que devuelven booleanos (por ejemplo, verdadero / falso). Si el objetivo principal de una función no es devolver un valor booleano (por ejemplo, printf, fopen, etc.), el valor de retorno se utiliza para indicar motivos de falla y luego puede adoptar la convención de UNIX de "silencio o 0 a menos hay un problema".

En cuanto a los valores de retorno, no hay nada de malo con el uso de valores de retorno fijos, hace que todo sea más conveniente.

El gran riesgo, en mi humilde opinión, es que muchas personas declaran sus propias constantes, y cuando otros usan los mismos archivos, comienzas a tener conflictos con sus propias constantes. Así que su VERDADERO / FALSO y el conflicto con alguien más es VERDADERO / FALSO en la línea.

Answer 7

Solo es malo si te quema. Si nunca trazas ningún error a esto, diría que estás bien. Lo que es más importante, es el comentario sobre la función que comienza con "Devuelve cero para ..."

La convención "no cero es un error" se usa cuando intentamos decir por qué junto con el indicador de error.

Answer 8

Yo diría que ambos son correctos, para diferentes propósitos:

Si está realizando una simple validación go / no-go, por ejemplo, is_numeric (), entonces verdadero y falso funcionan muy bien.

Para algo más elaborado, el paradigma 0 == success es útil ya que permite que se devuelva más de una condición de error.

En este caso, la persona que llama puede simplemente hacer una prueba en contra de 0, o examinar las declaraciones que no sean 0 para obtener una explicación más específica de la falla. por ejemplo, una llamada abierta de archivo puede fallar debido a la inexistencia, permisos insuficientes, etc.

Answer 9

para mí, en realidad, comparar con 0 parece más natural y el compilador lo optimiza de todos modos, así que me gusta escribir, por ejemplo

if (check_foo == 0) // hacer algo

Answer 10

Devuelve el valor por una función: convenciones para verdadero y falso O éxito y error:

1. Una API, etc. muestra el éxito con el valor de retorno 0 y la falla con el valor de retorno = valor de error distinto de cero.
2. Si algo es verdadero; funciones devuelven 1. Por ejemplo, isStackEmpty () devolverá 1 si la pila está vacía.

Answer 11

Todavía es completamente arbitrario devolver 1 o 0. Simplemente sea consistente y si hay códigos de error, al menos comente lo que significan en alguna parte.