participar - proyectos open source
C99 declaraciones mixtas y código en proyectos de código abierto? (7)
¿Por qué aún las declaraciones mixtas C99 y el código no se utilizan en proyectos de código abierto C como el kernel de Linux o GNOME ?
Me gustan mucho las declaraciones mixtas y el código, ya que hace que el código sea más legible y evita los errores difíciles de ver al restringir el alcance de las variables al mínimo posible. Esto es recomendado por Google para C ++ .
Por ejemplo, Linux requiere al menos GCC 3.2 y GCC 3.1 tiene soporte para declaraciones mixtas C99 y código
Hay pocas razones para reescribir el kernel de Linux para realizar cambios cosméticos que no ofrezcan mejoras de rendimiento.
Si la base de código funciona, ¿por qué cambiarla por razones estéticas?
No hay ninguna razón para cambiar el código de esta manera, y C99 todavía no es ampliamente compatible con los compiladores. Se trata principalmente de portabilidad.
No necesita declaración mixta ni código para limitar el alcance. Tu puedes hacer:
{
int c;
c = 1;
{
int d = c + 1;
}
}
en C89. En cuanto a por qué estos proyectos no han usado declaraciones mixtas (suponiendo que esto sea cierto), lo más probable es que sea el caso de "Si no está roto, no lo arregles".
Tal vez no sea necesario, ¿tal vez la separación es buena? Lo hago en C ++, que también tiene esta característica.
No hay beneficio Declarar todas las variables al principio de la función (tipo pascal) es mucho más claro, en C89 también puede declarar variables al comienzo de cada ámbito (ejemplo de bucles internos) que es práctico y conciso.
No recuerdo ninguna prohibición contra esto en la guía de estilo para el código kernel. Sin embargo, sí dice que las funciones deben ser lo más pequeñas posible, y solo hacer una cosa. Esto explicaría por qué una mezcla de declaraciones y códigos es rara.
En una función pequeña, declarar las variables al comienzo del alcance actúa como una especie de introito , que le dice algo sobre lo que vendrá poco después. En este caso, el movimiento de la declaración variable es tan limitado que probablemente no tenga ningún efecto, o sirva para ocultar cierta información sobre la funcionalidad empujando al ladrón a la multitud, por así decirlo. Hay una razón por la cual la llegada de un rey fue declarada antes de entrar a una habitación.
OTOH, una función que debe mezclar variables y código para ser legible es probablemente demasiado grande. Este es uno de los signos (junto con los bloques anidados, los comentarios en línea y otros) que algunas secciones de una función deben abstraerse en funciones separadas (y declaradas static , para que el optimizador pueda alinearlas).
Otra razón para guardar las declaraciones al comienzo de las funciones: si necesita reordenar la ejecución de las declaraciones en el código, puede mover una variable fuera de su alcance sin darse cuenta, ya que el alcance de una variable declarada en el medio del código no es evidente en la sangría (a menos que use un bloque para mostrar el alcance). Esto se soluciona fácilmente, por lo que es solo una molestia, pero el código nuevo a menudo sufre este tipo de transformación, y la molestia puede ser acumulativa.
Y otra razón: es posible que tengas la tentación de declarar una variable para tomar el código de retorno de error de una función, así:
void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }
Una cosa perfectamente razonable para hacer. Pero:
void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }
....
int ret = another_func_may_fail();
if (ret) { handle_other_fail(ret); }
Ooops! ret se define dos veces. "Entonces, quita la segunda declaración". tu dices. Pero esto hace que el código sea asimétrico, y terminas con más limitaciones de refactorización.
Por supuesto, mezclo declaraciones y código yo mismo; no hay razón para ser dogmático al respecto (de lo contrario, su karma puede atropellar su dogma :-). Pero debes saber cuáles son los problemas concomitantes.
Esta es una vieja pregunta, pero voy a sugerir que la inercia es la razón por la cual la mayoría de estos proyectos todavía usan reglas de declaraciones ANSI C.
Sin embargo, hay varias otras posibilidades, desde válidas hasta ridículas:
Portabilidad. Muchos proyectos de código abierto funcionan bajo la suposición de que el pedante ANSI C es la forma más portátil de escribir software.
Años. Muchos de estos proyectos son anteriores a la especificación C99 y los autores pueden preferir un estilo de codificación consistente.
Ignorancia. Los programadores que envían C99 son anteriores y no conocen los beneficios de las declaraciones mixtas y el código. (Interpretación alternativa: los desarrolladores son plenamente conscientes de las posibles compensaciones y deciden que las declaraciones y declaraciones mixtas no justifican el esfuerzo. Estoy muy en desacuerdo, pero es raro que dos programadores estén de acuerdo en algo).
FUD. Los programadores ven las declaraciones mixtas y el código como un "ismo de C ++" y no les gusta por esa razón.