estilos de programacion

Estilo de programación

‘El estilo de programación’ se refiere a la forma en que se da formato al código fuente. Para C, esto involucra la forma en que se ubican las llaves, se indenta el código y se utilizan los paréntesis. GNOME tiene una mezcla de estilos de programación y no se obliga el uso de ninguno de ellos. Lo más importante es que el código sea consistente dentro de un programa o una biblioteca — el código con un formato desordenado no es aceptable debido a que es difícil de leer.

Cuando escribas un nuevo programa o biblioteca, sigue un estilo consistente de ubicación de llaves y de indentación. Si no tienes ninguna preferencia personal de estilo, recomendamos el estilo de programación del núcleo de Linux o el estilo de programación de GNU.

Lee el nodo de info (Standards)Writing C en la documentación de GNU. Luego, obtén el código fuente de Linux y lee el archivo linux/Documentation/CodingStyle, e ignora los chistes de Linus. Estos dos documentos te darán una buena idea de nuestras recomendaciones para el código de GNOME.

Estilo de indentación

Para el código del núcleo de GNOME preferimos el estilo de indentación del núcleo de Linux. Usa tabuladores de 8 espacios para la indentación.

Usar tabuladores de 8 espacios para indentación proporciona un número de beneficios. Permite que el código sea más fácil de leer, ya que la indentación se marca claramente. También ayuda a mantener el código ordenado forzando a dividir funciones en trozos más modulares y bien definidos — si la indentación va más allá del margen derecho, significa que la función está mal diseñada y que debiera dividirse para hacerla más modular o bien, repensarla.

Los tabuladores de 8 espacios para indentación también ayudan al diseño de funciones que encajen bien en la pantalla, lo cual significa que las personas puedan entender el código sin tener que desplazarse atrás y adelante para entenderlo.

Si usas Emacs, entonces puedes seleccionar el estilo de indentación del núcleo de Linux incluyendo en el archivo .emacs lo siguiente:(add-hook 'c-mode-common-hook (lambda () (c-set-style "k&r") (setq c-basic-offset 8)))

En los nuevos Emacs o con el nuevo cc-mode, puedes ser capaz de hacerlo más simple con:(add-hook 'c-mode-common-hook (lambda () (c-set-style "linux")))

El estilo de indentación de GNU es el predeterminado para Emacs, así que no es necesario agregar nada en el archivo .emacs para habilitarlo. Si deseas seleccionarlo explícitamente, sustituye «gnu» por «linux» en el ejemplo anterior.

Si usas Vim, entonces puedes seleccionar el estilo de indentación del núcleo de Linux incluyendo el siguiente fragmento en el archivo .vimrc:set ts=8 if !exists("autocommands_loaded") let autocommands_loaded = 1 augroup C autocmd BufRead *.c set cindent augroup END endif

Como alternativa puedes seleccionar el estilo de indentación de GNU en Vim usando lo siguiente en el archivo .vimrc: [1]:augroup C autocmd BufRead *.c set cinoptions={.5s,:.5s,+.5s,t0,g0,^-2,e-2,n-2,p2s,(0,=.5s formatoptions=croql cindent shiftwidth=4 tabstop=8 augroup END

Nota

Si sabe personalizar el estilo de indentación en otros editores populares, por favor háganoslo saber y así podemos expandir este documento.

Convenciones de nombres

Es importante seguir una buena convención de nombres para los símbolos de los programas. Es específicamente importante para las bibliotecas, ya que no debería ensuciarse el espacio de nombres global — es muy molesto cuando una biblioteca tiene símbolos nombrados desordenadamente que chocan con nombres que pueda querer usar en sus programas.

Los nombres de las funciones deberían ser de la forma modulo_submodulo_operacion, por ejemplo, gnome_canvas_set_scroll_region o gnome_mime_get_keys. Esta convención elimina las colisiones de nombres de símbolos entre módulos. Es muy importante para las bibliotecas.

Los símbolos deben tener nombres descriptivos. Como Linus dice, no use cntusr(), sino que use count_active_users(). Esto permite que el código sea más fácil de leer y casi se auto documenta.

Intente usar las mismas convenciones de nombre que tienen GTK+ y las bibliotecas de GNOME:

Los nombres de las funciones en minúsculas, con líneas de subrayado para separar palabras, tal como: gnome_canvas_set_scroll_region(),gnome_mime_get_keys().

Las macros y las enumeraciones en mayúsculas, con líneas de subrayado para separar palabras, tal como: GNOMEUIINFO_SUBTREE() para una macro yGNOME_INTERACT_NONE para un valor enumerado.

Los nombres de tipos y estructuras usan una mezcla de mayúsculas y minúsculas, tal como: GnomeCanvasItem, GnomeIconList.

Al utilizar líneas de subrayado para separar palabras el código estará menos apretado y facilita la edición, ya que puede usar las secuencias de teclas que permiten navegar entre palabras más rápidamente en cualquier editor.

Si estás escribiendo una biblioteca, entonces puedes necesitar exportar símbolos que serán usados sólo dentro de la biblioteca. Por ejemplo, dos de los archivos objeto que componen la biblioteca libfoo.so pueden requerir acceder a símbolos ubicados en el otro archivo, pero se tiene la intención que éstos símbolos no sean utilizados desde los programas de usuario. En este caso, coloca una línea de subrayado antes del nombre de la función y haz que la primera palabra siga la convención estándar módulo/submódulo. Por ejemplo, podrías tener una función llamada _foo_internal_frobnicate().

Consistencia entre nombres

Es importante que las variables se nombren de manera consistente. Por ejemplo, un módulo que manipula una lista puedes elegir nombrar las variables que mantienen un puntero a la lista como «l», por elegancia y simplicidad. Sin embargo, es importante que un módulo que manipula widgets y tamaños no use variables llamadas «w» tanto para widgets y anchos («width») (como en valores de ancho/alto); esto podría hacer que el código sea inconsistente y difícil de leer.

Por supuesto, nombre muy cortos y elegantes solamente deberían ser usados para variables locales de funciones. Nunca llame una variable global «x»; use un nombre más largo que indique lo que signific