Los estándares de codificación GNU son un conjunto de reglas y pautas para escribir programas que funcionan de manera consistente dentro del sistema GNU . Los estándares de codificación GNU fueron escritos por Richard Stallman y otros voluntarios del Proyecto GNU. El documento de estándares es parte del Proyecto GNU y está disponible en el sitio web de GNU. Aunque se centra en escribir software libre para GNU en C , gran parte de él se puede aplicar de forma más general. En particular, el Proyecto GNU alienta a sus colaboradores a tratar siempre de seguir los estándares, ya sea que sus programas estén implementados en C.
Formato de código
Los estándares de codificación GNU especifican exactamente cómo formatear la mayoría de las construcciones del lenguaje de programación C. Aquí hay un ejemplo característico:
int main ( int argc , char * argv []) { struct gizmo foo ; fetch_gizmo ( & foo , argv [ 1 ]); comprobar : si ( foo . Tipo == MOOMIN ) pone ( "Es un moomin" ); más si ( foo . bar < GIZMO_SNUFKIN_THRESHOLD / 2 || ( strcmp ( foo . class_name , "Snufkin" ) == 0 ) && foo . bar < GIZMO_SNUFKIN_THRESHOLD ) pone ( "Es un Snufkin." ); else { char * barney ; / * Puntero al primer carácter después de la última barra en el nombre del archivo. * / int wilma ; / * Tamaño aproximado del universo. * / int fred ; / * Valor máximo del campo "barra". * / do { frobnicate ( & foo , GIZMO_SNUFKIN_THRESHOLD , & barney , & wilma , & fred ); twiddle ( & foo , barney , wilma + fred ); } while ( foo . bar > = GIZMO_SNUFKIN_THRESHOLD ); tamaño_tienda ( wilma ); ir a comprobar ; } return 0 ; }
El tratamiento consistente de los bloques como declaraciones (con el propósito de sangrar) es una característica muy distintiva del estilo de formato de código GNU C; como es el espacio obligatorio antes del paréntesis. Todo código formateado al estilo GNU tiene la propiedad de que cada llave de cierre, corchete o paréntesis aparece a la derecha de su delimitador de apertura correspondiente, o en la misma columna.
Como principio general, GNU Emacs puede ser considerado [¿ por quién? ] una autoridad confiable en el estilo de formato de código GNU. Como tal, es deseable [¿ según quién? ] que cualquier fragmento de código que se vea feo cuando Emacs lo sangra se cambia a una forma más amigable con Emacs, por ejemplo, insertando paréntesis adicionales.
Dividiendo largas filas
"Cuando divida una expresión en varias líneas, divídala antes de un operador, no después de uno". [1]
Por ejemplo:
si ( foo_this_is_long && barra > ganar ( x , y , z ) && remaining_condition )
Comentarios
Los estándares enfatizan enormemente la importancia de los comentarios en inglés :
Escriba los comentarios en un programa GNU en inglés, porque el inglés es el único idioma que pueden leer casi todos los programadores de todos los países. Si no escribe bien en inglés, escriba los comentarios en inglés lo mejor que pueda y luego pida a otras personas que le ayuden a reescribirlos. Si no puede escribir comentarios en inglés, busque a alguien que trabaje con usted y traduzca sus comentarios al inglés.
Los comentarios deben consistir en oraciones completas en mayúsculas, cada una seguida de dos espacios (para que Emacs pueda decir dónde termina una oración y comienza la siguiente).
Para condicionales de preprocesador largos o complejos, todos #else
y #endif
deben tener un comentario que explique la condición del código a continuación (para #else
) o superior (para #endif
).
Archivos
Las normas requieren que todos los programas sean capaces de operar cuando /usr
y /etc
están montados de sólo lectura. Por lo tanto, los archivos que son modificados para fines internos (archivos de registro, archivos de bloqueo, archivos temporales, etc.) no deben ser almacenados en cualquiera /usr
o /etc
. Se hace una excepción para los programas cuyo trabajo es actualizar los archivos de configuración del sistema en /etc
. Se hace otra excepción para almacenar archivos en un directorio cuando el usuario ha solicitado explícitamente modificar un archivo en el mismo directorio.
Portabilidad
Los estándares de codificación GNU definen el tema de la portabilidad de esta manera: portabilidad en el mundo Unix significa 'entre Unixes'; en un programa GNU, este tipo de portabilidad es deseable, pero no de vital importancia.
Según el estándar, los problemas de portabilidad son muy limitados ya que los programas GNU están diseñados para compilarse con un compilador, el compilador GNU C , y solo se ejecutan en un sistema, que es el sistema GNU.
Sin embargo, existe una forma de problema de portabilidad, y es el hecho de que el estándar deja en claro que un programa debe ejecutarse en diferentes tipos de CPU . El estándar dice que GNU no es compatible y no admitirá sistemas de 16 bits, pero el manejo de todos los diferentes sistemas de 32 y 64 bits es absolutamente necesario.
Crítica
Los estándares de codificación GNU son utilizados principalmente por proyectos GNU, aunque su uso no se limita solo a proyectos GNU.
El kernel de Linux desaconseja enérgicamente este estilo para el código del kernel y se refiere al estilo de manera peyorativa: "En primer lugar, sugeriría imprimir una copia de los estándares de codificación GNU y NO leerla. Grabarlos, es un gran gesto simbólico. ". [2] Steve McConnell , en su libro Code Complete , también desaconseja el uso de este estilo; marca una muestra de código que lo usa con un icono de "Coding Horror", que simboliza un código especialmente peligroso, y afirma que impide la legibilidad al requerir un nivel adicional de sangría para las llaves. [3]
Ver también
Referencias
- ^ "Estándares de codificación GNU" . www.gnu.org . Consultado el 29 de noviembre de 2020 .
- ^ "Estilo de codificación del kernel de Linux - La documentación del kernel de Linux" . www.kernel.org . Consultado el 12 de octubre de 2017 .
- ^ McConnell, Steve (2004). Code Complete: un manual práctico de construcción de software . Redmond, WA: Microsoft Press. págs. 746–747 . ISBN 0-7356-1967-0.