# HG changeset patch # User "German Poo-Caaman~o " # Date 1163641831 10800 # Node ID 4e44e6123b4277801c54eb5e3fd22091e3f90216 # Parent 4ca4c0227161092f490a715e2887a8549a621054 Recode from latin1 to utf-8 diff -r 4ca4c0227161 -r 4e44e6123b42 programming-guidelines.xml --- a/programming-guidelines.xml Mon Sep 11 23:39:36 2006 -0400 +++ b/programming-guidelines.xml Wed Nov 15 22:50:31 2006 -0300 @@ -10,7 +10,7 @@
- Guía de programación de GNOME + Guía de programación de GNOME @@ -43,7 +43,7 @@ Germán Poó Caamaño - Traducción al español + Traducción al español
gpoo@ubiobio.cl @@ -53,7 +53,7 @@ Lucas Vieites Fariña - Revisión de la traducción al español + Revisión de la traducción al español
lucas@asixinformatica.com @@ -63,7 +63,7 @@ Sergio Villar Senin - Revisión de la traducción al español + Revisión de la traducción al español
svillar@igalia.com @@ -77,19 +77,19 @@ 2004—2006 - GNOME Foundation, respecto de la versión en español. + GNOME Foundation, respecto de la versión en español. - Este artículo contiene varías guías y sugerencias para los - programadores de GNOME, así como ciertas políticas que - deberían seguirse cuando se escriben programas para GNOME. + Este artículo contiene varías guías y sugerencias para los + programadores de GNOME, así como ciertas políticas que + deberían seguirse cuando se escriben programas para GNOME. Es un intento para que los programadores puedan aprender - acerca del proceso de desarrollo de GNOME y su filosofía. - GNOME es un esfuerzo de equipo, así que será útil para - que los programadores sepan «la forma de hacer la - cosas». + acerca del proceso de desarrollo de GNOME y su filosofía. + GNOME es un esfuerzo de equipo, así que será útil para + que los programadores sepan «la forma de hacer la + cosas». @@ -97,59 +97,59 @@ - Introducción + Introducción - GTK+, la biblioteca de interfaz de usuario básica de GNOME, nos - ha enseñado algunas lecciones importantes en el diseño de software. - El código de GTK+ es limpio, consistente, mantenible y tiene - sentido. Tal código no sólo provoca placer al trabajar con el, - sino que además es un incentivo para las buenas prácticas de - programación para aquellos que quieran extenderlo y modificarlo. + GTK+, la biblioteca de interfaz de usuario básica de GNOME, nos + ha enseñado algunas lecciones importantes en el diseño de software. + El código de GTK+ es limpio, consistente, mantenible y tiene + sentido. Tal código no sólo provoca placer al trabajar con el, + sino que además es un incentivo para las buenas prácticas de + programación para aquellos que quieran extenderlo y modificarlo. - En este artículo intentamos presentar algunas sugerencias y - lineamientos que deberías tener en cuenta cuando escribas código - para el proyecto GNOME. Presentamos algunas de las políticas - que deben seguirse cuando se modifica el código de otras - personas, usando el repositorio CVS y asegurándose de que el - código se ajusta para ser incluído en GNOME. También - presentamos información que será útil para los mantenedores + En este artículo intentamos presentar algunas sugerencias y + lineamientos que deberías tener en cuenta cuando escribas código + para el proyecto GNOME. Presentamos algunas de las políticas + que deben seguirse cuando se modifica el código de otras + personas, usando el repositorio CVS y asegurándose de que el + código se ajusta para ser incluído en GNOME. También + presentamos información que será útil para los mantenedores de paquetes. - Además de este documento, asegúrate de leer los Estándares de - Programación de GNU. Estos se encuentran disponibles en el - nodo info (Standards) en la documentación - estándar de GNU. + Además de este documento, asegúrate de leer los Estándares de + Programación de GNU. Estos se encuentran disponibles en el + nodo info (Standards) en la documentación + estándar de GNU. - La importancia de escribir buen código + La importancia de escribir buen código GNOME es un proyecto de software libre muy ambicioso y, como tal, - está compuesto por muchos paquetes de software que son más o menos + está compuesto por muchos paquetes de software que son más o menos independientes el uno del otro. Mucho del trabajo en GNOME lo realizan voluntarios; programadores que vienen y se van - en cualquier momento y que serán capaces de dedicar + en cualquier momento y que serán capaces de dedicar diferentes cantidades de tiempo al proyecto GNOME. Muchas personas trabajan en software libre en su tiempo libre o - como un pasatiempo, así, si sus responsabilidades del ‘mundo - real’ cambian, se verá reflejado en la cantidad de trabajo que - dedicarán a proyectos de software libre. + como un pasatiempo, así, si sus responsabilidades del ‘mundo + real’ cambian, se verá reflejado en la cantidad de trabajo que + dedicarán a proyectos de software libre. Se tarda mucho tiempo en escribir software y supone una gran cantidad de trabajo. Es por esto que muchos de los voluntarios de tiempo parcial no pueden comenzar - grandes proyectos por sí mismos; es mucho más fácil y + grandes proyectos por sí mismos; es mucho más fácil y gratificante contribuir a proyectos existentes, puesto que los resultados son inmediatamente visibles y usables. @@ -159,26 +159,26 @@ software libre tiene recursos escasos, concluimos que para los proyectos existentes es muy importante facilitar, tanto como sea posible, que otras personas puedan contribuir. - Una forma de hacerlo es asegurándose de que los programas - sean fáciles de leer, entender y modificar. + Una forma de hacerlo es asegurándose de que los programas + sean fáciles de leer, entender y modificar. - El código desordenado es difícil de leer y las personas pueden - perder interés si no son capaces de descifrar lo que el código - intenta hacer. Además, es importante que los programadores sean - capaces de entender el código rápidamente, y así poder comenzar - a contribuir reparando fallos y extendiéndolo en un período breve - de tiempo. El código fuente es una forma de comunicación, y así - como a alguien podría no querer leer una novela con errores - ortográficos y mala puntuación, los programadores deben intentar - escribir buen código de tal forma que sea fácil de entender y + El código desordenado es difícil de leer y las personas pueden + perder interés si no son capaces de descifrar lo que el código + intenta hacer. Además, es importante que los programadores sean + capaces de entender el código rápidamente, y así poder comenzar + a contribuir reparando fallos y extendiéndolo en un período breve + de tiempo. El código fuente es una forma de comunicación, y así + como a alguien podría no querer leer una novela con errores + ortográficos y mala puntuación, los programadores deben intentar + escribir buen código de tal forma que sea fácil de entender y modificar por otros. Existen algunas cualidades que son importantes en un buen - código y por qué son importantes para los desarrolladores + código y por qué son importantes para los desarrolladores de software libre: @@ -186,9 +186,9 @@ Limpieza - Un código limpio es fácil de leer; permite a las - personas leerlo con un mínimo esfuerzo y así pueden - entenderlo más fácilmente. + Un código limpio es fácil de leer; permite a las + personas leerlo con un mínimo esfuerzo y así pueden + entenderlo más fácilmente. @@ -196,11 +196,11 @@ Consistencia - El código consistente permite más fácilmente que las + El código consistente permite más fácilmente que las personas entiendan como funciona el programa; cuando se - lee código consistente, subconcientemente uno se forma - un número de supuestos y expectativas acerca del - funcionamiento del código, de esta forma es más fácil + lee código consistente, subconcientemente uno se forma + un número de supuestos y expectativas acerca del + funcionamiento del código, de esta forma es más fácil y seguro realizarle modificaciones. @@ -209,27 +209,27 @@ Extensibilidad - El código de propósito general es más fácil de reutilizar - y modificar que el código demasiado específico con muchos - supuestos escritos directamente en el código (hardcoded). - Cuando alguien desea agregar una nueva característica - a un programa, obviamente será más fácil hacerlo si el - código fue diseñado para ser extensible desde el inicio. - El código que no fue escrito de esta forma hará que las + El código de propósito general es más fácil de reutilizar + y modificar que el código demasiado específico con muchos + supuestos escritos directamente en el código (hardcoded). + Cuando alguien desea agregar una nueva característica + a un programa, obviamente será más fácil hacerlo si el + código fue diseñado para ser extensible desde el inicio. + El código que no fue escrito de esta forma hará que las personas deban implementar hacks muy feos para poder - añadir características. + añadir características. - Corrección + Corrección - Finalmente, el código diseñado debe ser correcto para - que las personas pierdan menos tiempo preocupándose de + Finalmente, el código diseñado debe ser correcto para + que las personas pierdan menos tiempo preocupándose de los errores y se ocupen en extender las - características de un programa. Los usuarios también - apreciarán un código correcto, ya que a nadie le gusta + características de un programa. Los usuarios también + apreciarán un código correcto, ya que a nadie le gusta que un programa se caiga. @@ -239,82 +239,82 @@ En resumen, los programadores a menudo contribuyen en - su tiempo libre a proyectos de software libre, y aún quienes + su tiempo libre a proyectos de software libre, y aún quienes contribuyen de forma regular pueden detenerse en cualquier - instante del tiempo, así que es muy importante que el código + instante del tiempo, así que es muy importante que el código sea bueno y les permita modificarlo facilmente. El resultado - final será un mejor software al que los programadores - querrán extender. + final será un mejor software al que los programadores + querrán extender. - Estilo de programación + 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. + ‘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. + 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. + 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 + 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 + 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 + 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. + 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 + 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. + 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 + indentación del núcleo de Linux incluyendo en el archivo .emacs lo siguiente: @@ -324,7 +324,7 @@ (setq c-basic-offset 8))) En los nuevos Emacs o con el nuevo cc-mode, puedes ser capaz - de hacerlo más simple con: + de hacerlo más simple con: (add-hook 'c-mode-common-hook @@ -333,16 +333,16 @@ - El estilo de indentación de GNU es el predeterminado para - &Emacs;, así que no es necesario agregar nada en el + 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 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 + de indentación del núcleo de Linux incluyendo el siguiente fragmento en el archivo .vimrc: @@ -358,11 +358,11 @@ Como alternativa puedes seleccionar el estilo de - indentación de GNU en &Vim; usando lo siguiente en + indentación de GNU en &Vim; usando lo siguiente en el archivo .vimrc: - Gracias a Tomas Ögren por proporcionar este código. + Gracias a Tomas Ögren por proporcionar este código. : @@ -374,8 +374,8 @@ - Si sabe personalizar el estilo de indentación en otros - editores populares, por favor háganoslo saber y así podemos + Si sabe personalizar el estilo de indentación en otros + editores populares, por favor háganoslo saber y así podemos expandir este documento. @@ -387,29 +387,29 @@ 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 + 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 + 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 + 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. + 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 + 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 + que el código sea más fácil de leer y casi se auto documenta. @@ -420,7 +420,7 @@ - Los nombres de las funciones en minúsculas, con líneas + 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(). @@ -429,7 +429,7 @@ - Las macros y las enumeraciones en mayúsculas, con líneas + Las macros y las enumeraciones en mayúsculas, con líneas de subrayado para separar palabras, tal como: GNOMEUIINFO_SUBTREE() para una macro y GNOME_INTERACT_NONE para un valor @@ -440,31 +440,31 @@ Los nombres de tipos y estructuras usan una mezcla de - mayúsculas y minúsculas, tal como: + 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 + 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. + 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 + 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 + 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 + 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(). @@ -475,22 +475,22 @@ Es importante que las variables se nombren de manera - consistente. Por ejemplo, un módulo que manipula una + consistente. Por ejemplo, un módulo que manipula una lista puedes elegir nombrar las variables que mantienen - un puntero a la lista como «l», + 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. + 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 + 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 significa. + Nunca llame una variable global «x»; use + un nombre más largo que indique lo que significa. @@ -501,50 +501,50 @@ Limpieza - El código de GNOME debe ser tan limpio como sea posible. - Esto implica usar un estilo de indentación consistente - y una buena convención para nombrar símbolos, como se - ha indicado anteriormente. Esto también implica lo + El código de GNOME debe ser tan limpio como sea posible. + Esto implica usar un estilo de indentación consistente + y una buena convención para nombrar símbolos, como se + ha indicado anteriormente. Esto también implica lo siguiente. Aprender el uso correcto de la palabra reservada static. - No declarar todos los símbolos como + No declarar todos los símbolos como globales. Esto tiene la ventaja de poder usar nombres - más cortos dentro de las funciones en un sólo archivo + más cortos dentro de las funciones en un sólo archivo fuente, ya que no son globalmente visibles y por consiguiente no necesitas emplear el prefijo - módulo/submódulo. + módulo/submódulo. Aprender el uso correcto de la palabra reservada - const. Úsala consistentemente, - así permitirás al compilador que atrape muchos - errores estúpidos. + const. Úsala consistentemente, + así permitirás al compilador que atrape muchos + errores estúpidos. - Si tienes una función que retorna un puntero a + Si tienes una función que retorna un puntero a un dato interno que se supone que el usuario - no debe liberar, deberías usar el modificador - const. Este avisará al usuario si intenta - hacer alguna operación incorrecta, por ejemplo: + no debe liberar, deberías usar el modificador + const. Este avisará al usuario si intenta + hacer alguna operación incorrecta, por ejemplo: const char *gnome_mime_get_info (const char *info); - El compilador avisará si el usuario intenta liberar + El compilador avisará si el usuario intenta liberar la cadena retornada. Esto puede atrapar muchos errores. - Si tienes «valores mágicos» en el programa o + Si tienes «valores mágicos» en el programa o biblioteca, usa macros que los definan en vez de usarlos - directamente en el código: + directamente en el código: /* Amount of padding for GUI elements */ @@ -557,12 +557,12 @@ Si tienes una lista de valores posibles para una variable, no uses macros para ellas, usa enum para darle un nombre de tipo — esto permite disponer de nombres - simbólicos en un depurador. Además, no uses - «int» para almacenar un valor enumerado; usa + simbólicos en un depurador. Además, no uses + «int» para almacenar un valor enumerado; usa el tipo enum. Esto le permite al compilador atrapar - los errores por tí, permitiéndole al depurador mostrar los + los errores por tí, permitiéndole al depurador mostrar los valores apropiados y hacer obvios los valores que una - variable puede tomar. A continuación un ejemplo: + variable puede tomar. A continuación un ejemplo: /* Shadow types */ @@ -592,46 +592,46 @@ GNOME_CANVAS_UPDATE_IS_VISIBLE = 1 << 4 };]]> - Esto hace más fácil modificar la lista de valores y menos - propenso a error que especificando los valores a mano. También - permite usar estos valores como símbolos en un depurador. + Esto hace más fácil modificar la lista de valores y menos + propenso a error que especificando los valores a mano. También + permite usar estos valores como símbolos en un depurador. - No escribas código ofuscado, intenta que sea espartano. - Para clarificar una expresión, no uses más paréntesis que - los necesarios. Usa espacios antes de los paréntesis y - después de las comas y también alrededor de los operadores + No escribas código ofuscado, intenta que sea espartano. + Para clarificar una expresión, no uses más paréntesis que + los necesarios. Usa espacios antes de los paréntesis y + después de las comas y también alrededor de los operadores binarios. - No escribas hacks en el código. En vez de escribir un - hack feo, reescribe el código para que quede limpio, + No escribas hacks en el código. En vez de escribir un + hack feo, reescribe el código para que quede limpio, extensible y mantenible. - Asegúrate de que el código compila absolutamente sin ningún - aviso del compilador. Esto te ayudará a atrapar errores - estúpidos. Usa los prototipos de las funciones en los + Asegúrate de que el código compila absolutamente sin ningún + aviso del compilador. Esto te ayudará a atrapar errores + estúpidos. Usa los prototipos de las funciones en los archivos de encabezados de forma consistente. Dentro de GNOME puedes usar la macro de Autoconf GNOME_COMPILE_WARNINGS en el archivo - configure.in. Esto permitirá contar + configure.in. Esto permitirá contar con un buen conjunto de avisos del compilador de una manera portable. - Comenta el código. Coloca comentarios antes de - cada función para decir que hace. No digas cómo lo hace - a menos que sea absolutamente necesario; debería ser - obvio al leer el código. Si no lo fuera, entonces - puedes desear reescribirla hasta que sea fácil de + Comenta el código. Coloca comentarios antes de + cada función para decir que hace. No digas cómo lo hace + a menos que sea absolutamente necesario; debería ser + obvio al leer el código. Si no lo fuera, entonces + puedes desear reescribirla hasta que sea fácil de entender. @@ -639,10 +639,10 @@ Cuando documentes las funciones de la API de una biblioteca, sigue las directrices indicadas en el archivo gnome-libs/devel-docs/api-comment-style.txt. - Esto permite que el código fuente pueda proporcionar documentación - en línea, que posteriormente se extrae mediante el sistema + Esto permite que el código fuente pueda proporcionar documentación + en línea, que posteriormente se extrae mediante el sistema gtk-doc para crear un manual DocBook - de forma automática. + de forma automática. @@ -652,12 +652,12 @@ Se construye GNOME en muchas plataformas diferentes. - Se puede asumir que serán plataformas más o menos tipo Unix; + Se puede asumir que serán plataformas más o menos tipo Unix; hasta el momento GNOME no ha sido portado a sistema no-Unix, - así que se puede asumir que los servicios estándares de - Unix estarán disponibles. + así que se puede asumir que los servicios estándares de + Unix estarán disponibles. - ¿Servicios estándar de Unix? Por supuesto que estamos + ¿Servicios estándar de Unix? Por supuesto que estamos bromeando. @@ -665,53 +665,53 @@ Recuerda que el mundo no es tu propio equipo con GNU/Linux; - las gente realmente usa otros tipos de máquinas. + las gente realmente usa otros tipos de máquinas. - Intenta no usar extensiones específicas de - GCC debido a que éstas no - funcionarán con otros compiladores. Si realmente debes + Intenta no usar extensiones específicas de + GCC debido a que éstas no + funcionarán con otros compiladores. Si realmente debes hacer uso de tal cosa, ve la forma en que se hace en Glib con el conjunto de - macros G_GNUC; asegúrate también de incluir código - que funcione con compiladores ISO C. Si sólo tienes + macros G_GNUC; asegúrate también de incluir código + que funcione con compiladores ISO C. Si sólo tienes disponible GCC, aprende a usar las opciones que - permiten probar código sospechoso. + permiten probar código sospechoso. Recuerda que algunas plataformas no disponen de GCC o que GDB puede ser inusable en ellos, - y se querrán usar otros compiladores y depuradores. + y se querrán usar otros compiladores y depuradores. - Tópicos relacionados con GTK+ + Tópicos relacionados con GTK+ - GTK+ permite hacer mucha magia y ofuscación con manejadores - de señal, pasar cerraduras y conjuntos de datos. Si te + GTK+ permite hacer mucha magia y ofuscación con manejadores + de señal, pasar cerraduras y conjuntos de datos. Si te encuentras utilizando muchos gtk_object_set_data() en un mismo lugar, - o estas pasando estados de forma extraña a través de manejadores - de señales, reescribe el código. Si necesitas adjuntar muchos + o estas pasando estados de forma extraña a través de manejadores + de señales, reescribe el código. Si necesitas adjuntar muchos datos a un objeto en particular, entonces es un buen candidato - para una nueva clase derivada, que no sólo hará al código - más limpio, sino que también lo hará más extensible. + para una nueva clase derivada, que no sólo hará al código + más limpio, sino que también lo hará más extensible. - Mucha de la heurística en manejadores de eventos complicadas - a menudo se pueden reemplazar limpiando el código a través - de una máquina de estados. Esto es útil cuando se quieren - implementar cosas truculentas como selección y comportamientos - de arrastrado, y hará al código más fácil de depurar y extender. + Mucha de la heurística en manejadores de eventos complicadas + a menudo se pueden reemplazar limpiando el código a través + de una máquina de estados. Esto es útil cuando se quieren + implementar cosas truculentas como selección y comportamientos + de arrastrado, y hará al código más fácil de depurar y extender. @@ -720,14 +720,14 @@ - Corrección y robustez + Corrección y robustez - Es extremadamente importante que el código de GNOME sea - correcto y robusto. Esto significa que el código debería hacer - lo que se espera que haga y debería manejar bien las condiciones - de excepción. Aunque esto pueda parecer obvio, esta sección - dará algunas ideas para asegurar la corrección de tu código + Es extremadamente importante que el código de GNOME sea + correcto y robusto. Esto significa que el código debería hacer + lo que se espera que haga y debería manejar bien las condiciones + de excepción. Aunque esto pueda parecer obvio, esta sección + dará algunas ideas para asegurar la corrección de tu código de GNOME. Esto es muy importante, ya que los usuarios esperan y merecen un software confiable que se ejecute correctamente y que no se caiga. @@ -736,21 +736,21 @@ - Cómo asegurar la consistencia + Cómo asegurar la consistencia - Utiliza las macros de aserción de Glib para asegurarte + Utiliza las macros de aserción de Glib para asegurarte que el estado de un programa es consistente. Estas macros - ayudan a localizar errores muy rápidamente y se gastará + ayudan a localizar errores muy rápidamente y se gastará mucho menos tiempo en el depurado si se emplean de forma generosa y consistente. - Inserta verificaciones de sanidad en el código en puntos - importantes como es el inicio de funciones públicas, al - final de código que realiza una búsqueda que siempre + Inserta verificaciones de sanidad en el código en puntos + importantes como es el inicio de funciones públicas, al + final de código que realiza una búsqueda que siempre debe ser exitosa y en cualquier lugar donde el rango de valores calculados es importante. @@ -765,36 +765,36 @@ Las aserciones y precondiciones ayudan a asegurar que el estado de un programa es consistente. Glib proporciona macros para colocar aserciones y precondiciones en el - código. Deberías usarlas libremente; a cambio podrás - localizar errores muy rápidamente y ocuparás menos tiempo + código. Deberías usarlas libremente; a cambio podrás + localizar errores muy rápidamente y ocuparás menos tiempo rastreando errores con el depurador. Existen macros de Glib para precondiciones, las cuales - emiten un mensaje cuando una condición falla y retornan - de la función desde donde fueron llamadas. Debieran ser + emiten un mensaje cuando una condición falla y retornan + de la función desde donde fueron llamadas. Debieran ser usadas en el inicio de las funciones. g_return_if_fail - (condición) + (condición) - Retorna desde la línea actual de la función si la - condición es falsa. + Retorna desde la línea actual de la función si la + condición es falsa. - g_return_val_if_fail (condición, + g_return_val_if_fail (condición, valor) Retorna el valor indicado desde - la función actual si la condición + la función actual si la condición es falsa. @@ -803,18 +803,18 @@ - También existen macros para aserciones. Estas emitirán - un mensaje cuando una condición falle y llamará a la - función abort(3) para terminar el + También existen macros para aserciones. Estas emitirán + un mensaje cuando una condición falle y llamará a la + función abort(3) para terminar el programa. Debieran ser usadas para asegurarse la - consistencia para códigos internos. + consistencia para códigos internos. - g_assert (condición) + g_assert (condición) - Aborta el programa si la condición + Aborta el programa si la condición es falsa. @@ -833,103 +833,103 @@ Estas funciones debieran emplearse para imponer - precondiciones en el código y verificar su corrección + precondiciones en el código y verificar su corrección — piensa en ellas como verificaciones de sanidad en los programas. Debieras usarlas libremente como - asistencia para atrapar los errores rápidamente; una + asistencia para atrapar los errores rápidamente; una vez que el programa se encuentre completamente depurado, - puedes compilarlo con estas macros deshabilitadas y así - evitar añadirle sobrecarga al momento de ejecutarlos. + puedes compilarlo con estas macros deshabilitadas y así + evitar añadirle sobrecarga al momento de ejecutarlos. Las macros g_return_*() debieran - emplearse al inicio de las funciones públicas de las + emplearse al inicio de las funciones públicas de las bibliotecas, para asegurarse de que los argumentos que se pasan - a ellas sean correctos y tengan un rango válido. Si - una función no retorna valor (por ejemplo, retorna + a ellas sean correctos y tengan un rango válido. Si + una función no retorna valor (por ejemplo, retorna void), debieras usar g_return_if_fail(). En caso contrario, debiera usar g_return_val_if_fail() para retornar un valor ‘seguro’. Cuando - se invoca una función de biblioteca que usa estas macros - con un argumento incorrecto , se producirá un - mensaje de error y continuará la ejecución. El - programa cliente podrá tener algún sobresalto, hacer - nada o caerse, pero al menos sabrá - dónde se le ha pasado un valor - incorrecto a la función. + se invoca una función de biblioteca que usa estas macros + con un argumento incorrecto , se producirá un + mensaje de error y continuará la ejecución. El + programa cliente podrá tener algún sobresalto, hacer + nada o caerse, pero al menos sabrá + dónde se le ha pasado un valor + incorrecto a la función. La macro g_assert() debiera usarse para asegurar la consistencia interna de una biblioteca o - programa. En vez de retornar de la función y continuar - la ejecución si la condición falla, - g_assert() producirá en mensaje de error - e inmediatamente abortará el programa. Esto es para - evitar que el programa continúe ejecutándose en un + programa. En vez de retornar de la función y continuar + la ejecución si la condición falla, + g_assert() producirá en mensaje de error + e inmediatamente abortará el programa. Esto es para + evitar que el programa continúe ejecutándose en un estado inconsistente. Debieras usar esta macro para - asegurarte de que el programa o biblioteca está usando + asegurarte de que el programa o biblioteca está usando valores internos sanos. La macro g_assert_not_reached() se - usa para marcar el lugar en el código que nunca + usa para marcar el lugar en el código que nunca debiera producirse. Por ejemplo, si tienes una - cláusula switch y piensas que manejas + cláusula switch y piensas que manejas todos los valores posibles en las etiquetas case, entonces debieras colocar g_assert_not_reached() en la etiqueta default para asegurarte de que - el código nunca llegue allá (podría significar que - ha perdido algún valor o que el programa se encuentra + el código nunca llegue allá (podría significar que + ha perdido algún valor o que el programa se encuentra incorrecto). - Estas macros ayudan a encontrar errores más rápido - a través de avisos que se producen tan pronto como - el programa alcanza un estado incosistente. Úsalos - frecuentemente y encontrarás muchos errores más - fácilmente. + Estas macros ayudan a encontrar errores más rápido + a través de avisos que se producen tan pronto como + el programa alcanza un estado incosistente. Úsalos + frecuentemente y encontrarás muchos errores más + fácilmente. - Tópicos relacionados con GTK+ + Tópicos relacionados con GTK+ Debe ser cuidadoso cuando escribas manejadores de eventos — asegurate de que los eventos son manipulados en las situaciones apropiadas. Es necesario asegurarse de - que los manejadores de señales tengan los prototipos + que los manejadores de señales tengan los prototipos correctos. Esto es muy importante. Recuerda que no - todos los prototipos de manejadores de señal se parecen + todos los prototipos de manejadores de señal se parecen a lo siguiente: static void my_handler (GtkWidget *widget, gpointer data); - Por ejemplo, los manejadores de eventos tienen un parámetro + Por ejemplo, los manejadores de eventos tienen un parámetro extra de evento y retornan gint. Revisa los archivos de encabezado de GTK+ cuando necesites verificarlo. - Asegúrate que el programa trata de una forma apropiada + Asegúrate que el programa trata de una forma apropiada todas las acciones generadas por el usuario. Recuerda que el usuario puede cerrar una ventana en cualquier - momento a través del administrador de ventanas; tenlo - presente y escribe el código necesario para manejar esta - situación. + momento a través del administrador de ventanas; tenlo + presente y escribe el código necesario para manejar esta + situación. - Si verificas los modificadores de teclas con una máscara + Si verificas los modificadores de teclas con una máscara de estado de eventos, por ejemplo, ControlF10 escribe lo siguiente: @@ -949,11 +949,11 @@ if (event->keysym == GDK_F10 && event->state == GDK_CONTROL_MASK) - entonces el programa no funcionará correctamente si el + entonces el programa no funcionará correctamente si el usuario tiene, por ejemplo, activada la tecla NumLock — NumLock - también es un modificador, y si está activado, entonces - la máscara de estado del evento no será como se espera + también es un modificador, y si está activado, entonces + la máscara de estado del evento no será como se espera en el segundo ejemplo. @@ -963,50 +963,50 @@ Vistas y mapas de color - - Algunos usuarios utilizan tarjetas de vídeo avanzadas - (por ejemplo, SGIs y Suns) que soportan múltiples vistas - simúltaneamente. Una vista define la representación en memoria + Algunos usuarios utilizan tarjetas de vídeo avanzadas + (por ejemplo, SGIs y Suns) que soportan múltiples vistas + simúltaneamente. Una vista define la representación en memoria que usa un dispositivo de hardware para almacenar los - contenidos de una imagen. Muchas tarjetas de vídeo de - PC soportan sólo una vista a la vez, pero el hardware + contenidos de una imagen. Muchas tarjetas de vídeo de + PC soportan sólo una vista a la vez, pero el hardware avanzado puede tener diferentes ventanas y pixmaps en - diferentes vistas simultáneamente. + diferentes vistas simultáneamente. Es importante entender las vistas y mapas de colores si - vas a escribir código que crea ventanas y pixmaps por tus + vas a escribir código que crea ventanas y pixmaps por tus propios medios, en vez de utilizar las funciones de alto - nivel como GnomeCanvas y GnomePixmap. Para mayor información, - lea el manual de programación de Xlib. + nivel como GnomeCanvas y GnomePixmap. Para mayor información, + lea el manual de programación de Xlib. - En general, sólo necesitas recordar que la vista y el mapa - de colores de un área de dibujo debe coincidir con los de - otra área de dibujo si deseas copiar un trozo desde la - primera área de dibujo a la segunda. Si no son las mismas, - podrías obtener el mensaje «BadMatch error» del servidor X y - tu aplicación muy probablemente abortará su ejecución. + En general, sólo necesitas recordar que la vista y el mapa + de colores de un área de dibujo debe coincidir con los de + otra área de dibujo si deseas copiar un trozo desde la + primera área de dibujo a la segunda. Si no son las mismas, + podrías obtener el mensaje «BadMatch error» del servidor X y + tu aplicación muy probablemente abortará su ejecución. - Si creas un contexto gráfico (GC) y lo compartes para pintar - en varias áreas de dibujo, asegúrate que todas ellas tengan + Si creas un contexto gráfico (GC) y lo compartes para pintar + en varias áreas de dibujo, asegúrate que todas ellas tengan la misma vista y mapa de colores que fue definido para el - GC. Lo mismo se aplica si quieres copiar un área desde un + GC. Lo mismo se aplica si quieres copiar un área desde un pixmap a una ventana; ambos deben tener la misma vista y mapa de colores. - Si no estás seguro de que tu código lo hace correctamente, + Si no estás seguro de que tu código lo hace correctamente, pregunta educadamente, en una de las listas de correo de desarrollo de GNOME, si alguien puede realizar una prueba con - una tarjeta de video que soporta esta característica. Dicha - persona sabrá como arreglar el problema y te dirá al respecto. + una tarjeta de video que soporta esta característica. Dicha + persona sabrá como arreglar el problema y te dirá al respecto. @@ -1021,15 +1021,15 @@ las llamadas al sistema que el programa realice. Recuerda que muchas de las llamadas al sistema pueden ser interrumpidas (por ejemplo, la llamada retorna - -1 y errno será definido a + -1 y errno será definido a EINTR) y deben reiniciarse. - No asumas, por ejemplo, que la función - write(2) escribirá el buffer completo + No asumas, por ejemplo, que la función + write(2) escribirá el buffer completo de una vez; tienes que verificar el valor de retorno, el cual - indica el número de bytes escritos e intenta nuevamente + indica el número de bytes escritos e intenta nuevamente hasta que sea cero. Si el valor de retorno es -1, recuerda verificar el valor de errno y manejar el error @@ -1037,17 +1037,17 @@ - Si la aplicación llama a la función fork(2) + Si la aplicación llama a la función fork(2) sin llamar a execve(2), recuerda que el proceso hijo no puede hacer llamadas X. Normalmente se - puede diagnosticar este problema a través de un oscuro + puede diagnosticar este problema a través de un oscuro mensaje de error de Xlib. - Lee el libro «Advanced programming in the Unix - environment», de Richard Stevens, para aprender acerca de - todos estos teassertmas y asegúrate que tus programas usan + Lee el libro «Advanced programming in the Unix + environment», de Richard Stevens, para aprender acerca de + todos estos teassertmas y asegúrate que tus programas usan la API de Unix de forma correcta. Si no deseas asegurarte del uso correcto de las llamadas Unix, pregunta en las listas de correo. @@ -1061,28 +1061,28 @@ Consideraciones de seguridad - La seguridad es un tema complejo y en esta sección no se + La seguridad es un tema complejo y en esta sección no se puede explicar ni de lejos todo lo relacionado. - Intentaremos indicar las situaciones más comunes donde tus + Intentaremos indicar las situaciones más comunes donde tus programas deben interesarse por la seguridad. - Es muy fácil crear hoyos de seguridad a través de la creación + Es muy fácil crear hoyos de seguridad a través de la creación incorrecta de archivos temporales en /tmp. - Debes garantizar que los archivos que usarás no existen al - momento de su creación. Usar un nombre de archivo «único» - e «impredecible» no es suficiente; debes garantizar que el archivo - con ese nombre no será creado por alguien más entre el tiempo + Debes garantizar que los archivos que usarás no existen al + momento de su creación. Usar un nombre de archivo «único» + e «impredecible» no es suficiente; debes garantizar que el archivo + con ese nombre no será creado por alguien más entre el tiempo en que se determina el nombre y el tiempo en que es efectivamente - creado (básicamente los ataques involucran que un tercero - cree un enlace simbólico al archivo que ellos quieren + creado (básicamente los ataques involucran que un tercero + cree un enlace simbólico al archivo que ellos quieren sobreescribir). - Afortunadamente, esto es fácil de hacer. Usa el siguiente trozo - de código: + Afortunadamente, esto es fácil de hacer. Usa el siguiente trozo + de código: char *filename; @@ -1099,86 +1099,86 @@ free (filename); } while (fd == -1); - Recuerde liberar filename usando la función + Recuerde liberar filename usando la función free() y llamar a las funciones close() y unlink() - con el archivo respectivo cuando haya terminado; aquí + con el archivo respectivo cuando haya terminado; aquí liberamos filename con free() - inmediatamente y así no causará una pérdida de memoria. + inmediatamente y así no causará una pérdida de memoria. - Si deseas usar la biblioteca estándar de E/S, puede usar la - función fdopen() para transformar el + Si deseas usar la biblioteca estándar de E/S, puede usar la + función fdopen() para transformar el descriptor de archivo en FILE *, o puedes - usar la función tmpfile() para hacerlo + usar la función tmpfile() para hacerlo en un solo paso. - Intenta no usar buffers de tamaño fijo. Los buffers de tamaño - fijo para cadenas constituyen los típicas fuentes de hoyos + Intenta no usar buffers de tamaño fijo. Los buffers de tamaño + fijo para cadenas constituyen los típicas fuentes de hoyos explotables que pueden llegar a oscuros errores. Si definitivamente - debes usar buffers de tamaño fijo para cadenas, usa la función - g_snprintf() para especificar el tamaño - máximo del buffer. + debes usar buffers de tamaño fijo para cadenas, usa la función + g_snprintf() para especificar el tamaño + máximo del buffer. - Glib proporciona la, muy conveniente, función + Glib proporciona la, muy conveniente, función g_strdup_printf(), la cual funciona como - sprintf() pero automáticamente - localizará un buffer con el tamaño correcto. El valor de retorno - de esta función debiera ser liberada usando - g_free(). A menudo es más conveniente de + sprintf() pero automáticamente + localizará un buffer con el tamaño correcto. El valor de retorno + de esta función debiera ser liberada usando + g_free(). A menudo es más conveniente de usar que g_snprintf(), ya que esta no - limita el tamaño de las cadenas que un programa puede manipular. + limita el tamaño de las cadenas que un programa puede manipular. - Si deseas concatenar un grupo de cadenas, puedes usar la función + Si deseas concatenar un grupo de cadenas, puedes usar la función g_strconcat(), la cual recibe una lista variable de cadenas y un puntero a NULL - como último argumento. + como último argumento. Bajo ninguna circunstancia crees un programa GTK+ con setuid root. Las bibliotecas de GTK+ y - GNOME son grandes y complejas y no han tenido auditorías + GNOME son grandes y complejas y no han tenido auditorías de seguridad. En cualquier caso, no debieras querer que - una pieza tan grande código sea setuid root. Si definitivamente + una pieza tan grande código sea setuid root. Si definitivamente requieres usar privilegios de root para algo, escribe un programa que sea la interfaz de usuario como un proceso normal, sin privilegios y crea un programa nexo que tenga setuid y se encargue de realizar la operaciones - «peligrosas». Además, notifica a las listas + «peligrosas». Además, notifica a las listas de correo de desarrollo de GNOME indicando que requieres - que alguien realice una auditoría de seguridad a tu + que alguien realice una auditoría de seguridad a tu programa nexo. - En general, si no estás seguro si puedes crear un riesgo de + En general, si no estás seguro si puedes crear un riesgo de seguridad, pregunte en las listas de correo de desarrollo de GNOME. - Puedes leer más sobre temas de seguridad que debieras encontrar - cuando programes una aplicación Unix en el documento - «Murphy's - Law and Computer Security», de Wietse Wenema. + Puedes leer más sobre temas de seguridad que debieras encontrar + cuando programes una aplicación Unix en el documento + «Murphy's + Law and Computer Security», de Wietse Wenema. Hay otros documentos de seguridad en el sitio fish.com - que podrías encontrar interesante. + que podrías encontrar interesante. - Puedes encontrar muchas otras guías útiles para escribir programas + Puedes encontrar muchas otras guías útiles para escribir programas seguros en «Secure - Programming for Linux and Unix HOWTO». + url="http://www.dwheeler.com/secure-programs">«Secure + Programming for Linux and Unix HOWTO». @@ -1188,72 +1188,72 @@ Rendimiento - No leas esta sección hasta que estés seguro que tu programa está - correcto, por ejemplo, cuando estés seguro que funciona - correctamente y no tiene errores. Es más importante que - el código sea correcto a que sea rápido. Un programa lento - pero correcto es mucho mejor a uno rápido pero con errores. + No leas esta sección hasta que estés seguro que tu programa está + correcto, por ejemplo, cuando estés seguro que funciona + correctamente y no tiene errores. Es más importante que + el código sea correcto a que sea rápido. Un programa lento + pero correcto es mucho mejor a uno rápido pero con errores. Si quieres optimizar tu programa, el primer paso es determinar - un perfil al programa ejecutándolo con datos de la vida real - y recopilar puntos calientes que requieran optimización. - Esto ayudará a determinar los lugares que necesitan optimizarse. - Es importante que nunca adelantes la optimización si no tienes - una idea clara sobre donde está el problema. Podrías terminar + un perfil al programa ejecutándolo con datos de la vida real + y recopilar puntos calientes que requieran optimización. + Esto ayudará a determinar los lugares que necesitan optimizarse. + Es importante que nunca adelantes la optimización si no tienes + una idea clara sobre donde está el problema. Podrías terminar perdiendo el tiempo en agilizar una rutina que no es la causa - del cuello de boteLla y como resultado podrías terminar ofuscando - dicha rutina. Esto podría reducir la legibilidad y mantenibilidad - del código sin ganancia visible en velocidad. + del cuello de boteLla y como resultado podrías terminar ofuscando + dicha rutina. Esto podría reducir la legibilidad y mantenibilidad + del código sin ganancia visible en velocidad. - Un código sencillo es bueno porque es fácil de entender y - mantener. Si puedes escribir código simple que además sea - potente y rápido, tanto mejor. Si tienes un trozo de código - inteligente pero que no es fácil de seguir, entonces documéntalo + Un código sencillo es bueno porque es fácil de entender y + mantener. Si puedes escribir código simple que además sea + potente y rápido, tanto mejor. Si tienes un trozo de código + inteligente pero que no es fácil de seguir, entonces documéntalo para que las personas no lo estropeen accidentalmente. - No escribas código que sea difícil de leer y mantener por el - sólo hecho de hacerlo más rápido. En cambio, prefiere un algoritmo - agradable y claro e impleméntalo claramente. + No escribas código que sea difícil de leer y mantener por el + sólo hecho de hacerlo más rápido. En cambio, prefiere un algoritmo + agradable y claro e impleméntalo claramente. Hacer un buen trabajo en el caso general es a menudo mejor que - tener muchos casos especiales. Sólo provee casos especiales - cuando se han identificado puntos débiles en el programa. + tener muchos casos especiales. Sólo provee casos especiales + cuando se han identificado puntos débiles en el programa. - Administración de listas en Glib + Administración de listas en Glib Evita emplear construcciones que terminen ralentizando los algoritmos. Si usas g_list_insert_sorted() o - g_list_append() sin ningún cuidado, - fácilmente puedes tener un algoritmo que se ejecuta en + g_list_append() sin ningún cuidado, + fácilmente puedes tener un algoritmo que se ejecuta en tiempo proporcional a O(n2). - Normalmente puedes crear listas hacia atrás, usando - g_list_prepend(), e invirtiéndola + Normalmente puedes crear listas hacia atrás, usando + g_list_prepend(), e invirtiéndola cuando hayas terminado usando g_list_reverse(). Esta es una - operación O(n). Y si necesitas una lista ordenada, puedes - crearla de la misma forma (hacia atrás) y una vez terminado, + operación O(n). Y si necesitas una lista ordenada, puedes + crearla de la misma forma (hacia atrás) y una vez terminado, usar g_list_sort(). Si necesitas una lista ordenada en todo momento, puede ser - mejor emplear un estructura de árbol o un híbrido - lista/árbol. Si necesitas construir una lista añadiendo - nodos a ella, mantén un puntero al final de la lista - y ve cambiándola según sea apropiado; esto te permitirá + mejor emplear un estructura de árbol o un híbrido + lista/árbol. Si necesitas construir una lista añadiendo + nodos a ella, mantén un puntero al final de la lista + y ve cambiándola según sea apropiado; esto te permitirá insertar un nodo al inicio o al final en un tiempo constante. @@ -1262,24 +1262,24 @@ - Localización + Localización Se pretende que GNOME pueda ejecutarse en distintas localidades y lenguajes, y los programas debieran tener esto en cuenta. No - tienes que localizar los programas, sólo debes permitir que éstos + tienes que localizar los programas, sólo debes permitir que éstos sean traducibles y localizables. Debes recordar que los diferentes idiomas humanos tienen diferentes - gramáticas, así que no debieras suponer la forma de estructurar + gramáticas, así que no debieras suponer la forma de estructurar cada frase. Esto es importante, por ejemplo, cuando se construyen cadenas a partir de trozos separados. - La concatenación normalmente no es la forma correcta de construir + La concatenación normalmente no es la forma correcta de construir una cadena para que sea presentada al usuario. Normalmente terminan en mensajes que no pueden ser traducidos correctamente en todos los idiomas. En vez de concatenar, intenta usar @@ -1296,13 +1296,13 @@ char *message = g_strdup_printf (_("Hello, %s, would you like fries with that?"), name); - Esto permitirá al traductor mover %s donde corresponda según - lo requiera la gramática del idioma en el cual trabaja. + Esto permitirá al traductor mover %s donde corresponda según + lo requiera la gramática del idioma en el cual trabaja. - Recuerda que no todos los idiomas forman los plurales añadiendo - una «s» a las palabras. Además, las estructuras de + Recuerda que no todos los idiomas forman los plurales añadiendo + una «s» a las palabras. Además, las estructuras de frases pueden cambiar con los plurales. Por ejemplo, @@ -1322,20 +1322,20 @@ - Si el programa muestra fechas u horas, usa la función + Si el programa muestra fechas u horas, usa la función strftime() para darles formato como - cadenas. Esto se encargará de usar la representación - adecuada de fecha y hora de acuerdo a la definición local - del usuario. Además, si el programa debe generar una - representación visual de un calendario, recuerda que en - algunos países se considera como primer día de la semana + cadenas. Esto se encargará de usar la representación + adecuada de fecha y hora de acuerdo a la definición local + del usuario. Además, si el programa debe generar una + representación visual de un calendario, recuerda que en + algunos países se considera como primer día de la semana el domingo y no el lunes. El programa debiera permitir ambas formas de calendarios. - Si el programa usa medidas, asegúrate de permitir tanto - el sistema métrico decimal como el sistema imperial (o anglosajón). + Si el programa usa medidas, asegúrate de permitir tanto + el sistema métrico decimal como el sistema imperial (o anglosajón). @@ -1347,75 +1347,75 @@ Para bibliotecas estables y ya liberadas, es muy importante intentar preservar la compatibilidad binaria en las revisiones - mayores del código. Los desarrolladores de bibliotecas deben + mayores del código. Los desarrolladores de bibliotecas deben intentar no alienar a los usuarios realizando de forma frecuente cambios que sean binariamente incompatibles en bibliotecas que - son de producción. Por supuesto, en aquellas bibliotecas que se - encuentran en desarrollo o están etiquetadas como no finalizadas + son de producción. Por supuesto, en aquellas bibliotecas que se + encuentran en desarrollo o están etiquetadas como no finalizadas puedes realizar tantos cambios como se necesiten. - Una biblioteca típicamente exporta un número de interfaces. Estas + Una biblioteca típicamente exporta un número de interfaces. Estas incluyen nombres de rutinas, las firmas o prototipos de estas rutinas, variables globales, estructuras, campos de estructura (tanto los tipos como su significado), el significado de los - valores enumerados y la semántica de los archivos que la + valores enumerados y la semántica de los archivos que la biblioteca crea. Mantener compatibilidad binaria significa que - estas interfaces no cambiarán. Puedes añadir nuevas interfaces + estas interfaces no cambiarán. Puedes añadir nuevas interfaces sin romper la compatibilidad binaria, pero no puedes cambiar - las ya existentes, ya que los programas antiguos no se ejecutarán + las ya existentes, ya que los programas antiguos no se ejecutarán correctamente. - Esta sección incluye un número de ideas acerca de como lograr - que el código de una biblioteca sea compatible con sus + Esta sección incluye un número de ideas acerca de como lograr + que el código de una biblioteca sea compatible con sus versiones anteriores. Mantener la compatibilidad binaria significa que los programas - y archivos objetos que fueron compilados con una versión - previa del código continuarán funcionando sin recompilar aún + y archivos objetos que fueron compilados con una versión + previa del código continuarán funcionando sin recompilar aún cuando la biblioteca sea reemplazada. Es posible encontrar - una descripción detallada en el nodo info - (libtool)Interfaces de la documentación + una descripción detallada en el nodo info + (libtool)Interfaces de la documentación de GNU libtool. - Información privada en las estructuras + Información privada en las estructuras - En el sistema GNOME es una tarea muy común crear un + En el sistema GNOME es una tarea muy común crear un nuevo GtkObject para crear una estructura cuyo primer miembro corresponde a la clase de la cual hereda este objeto y posteriormente - un número de variables de instancia que se añaden - después del primer miembro. + un número de variables de instancia que se añaden + después del primer miembro. - Este esquema de diseño normalmente lleva a que el código - sea difícil de actualizar y cambiar: si se quiere + Este esquema de diseño normalmente lleva a que el código + sea difícil de actualizar y cambiar: si se quiere extender un objeto donde se necesita mantener su estado interno, los programadores necesitan recurrir a varios - hacks para mantener el mismo tamaño de las estructuras. - Esto hace difícil agregar nuevos campos a las estructuras - públicas sin romper la compatibilidad binaria, ya que - los campos de la estructura pueden cambiar y el tamaño + hacks para mantener el mismo tamaño de las estructuras. + Esto hace difícil agregar nuevos campos a las estructuras + públicas sin romper la compatibilidad binaria, ya que + los campos de la estructura pueden cambiar y el tamaño de las estructuras pueden variar. Por consiguiente, se sugiere una estrategia que puedan adoptar los desarrolladores en el momento de crear nuevos - objetos. Esta estrategia asegurará la compatibilidad - binaria y al mismo tiempo mejorará la legibilidad y - mantenibilidad del código. + objetos. Esta estrategia asegurará la compatibilidad + binaria y al mismo tiempo mejorará la legibilidad y + mantenibilidad del código. @@ -1423,17 +1423,17 @@ debiera crear tres archivos: el primero que contiene el contrato entre la biblioteca y el usuario (esto es el archivo de encabezado que se instala en el - sistema); el segundo contiene la implementación del - objeto; y el tercer archivo contiene la definición + sistema); el segundo contiene la implementación del + objeto; y el tercer archivo contiene la definición de la estructura para los campos privados o internos - que no necesitan estar en la estructura pública. + que no necesitan estar en la estructura pública. - La API pública de la estructura podría incluir un - puntero a un elemento privado, el cual podría + La API pública de la estructura podría incluir un + puntero a un elemento privado, el cual podría apuntar a los datos privado de la instancia. Las - rutinas de implementación podría dereferenciar + rutinas de implementación podría dereferenciar este punto para acceder a los datos privados; por supuesto, el puntero apunta a la estructura que se localiza privadamente. @@ -1441,7 +1441,7 @@ Por ejemplo, imagina que se crea el objeto GnomeFrob. - La implementación del widget será dividido en tres + La implementación del widget será dividido en tres archivos: @@ -1458,20 +1458,20 @@ gnome-frob.h - API pública de GnomeFrob + API pública de GnomeFrob gnome-frob.c - Implementación del objeto Gnomefrob + Implementación del objeto Gnomefrob gnome-frob-private.h - Datos privados de la implementación de GnomeFrob. + Datos privados de la implementación de GnomeFrob. Debieras querer usar esto si planea compartir los - datos privados a través de varios archivos C. Si - limitas el uso de la información privada a sólo un + datos privados a través de varios archivos C. Si + limitas el uso de la información privada a sólo un archivo, no necesita esto, ya que al definir la - estructura en el archivo de implementación se logrará + estructura en el archivo de implementación se logrará el mismo efecto. @@ -1481,7 +1481,7 @@ - Ejemplo de la API pública de <filename>gnome-frob.h</filename> + <title>Ejemplo de la API pública de <filename>gnome-frob.h</filename> typedef struct _GnomeFrob GnomeFrob; @@ -1508,7 +1508,7 @@ - Ejemplo de la implementación de + <title>Ejemplo de la implementación de <filename>gnome-frob.c</filename>. void gnome_frob_frobate (GnomeFrob *frob) @@ -1520,59 +1520,59 @@ } - Fíjese en el uso de prototipos de estructura: esto permite que - el compilador realice más verificaciones en tiempo de - compilación respecto a los tipos que estan siendo empleados. + Fíjese en el uso de prototipos de estructura: esto permite que + el compilador realice más verificaciones en tiempo de + compilación respecto a los tipos que estan siendo empleados. - Este esquema es útil en algunas situaciones, particularmente + Este esquema es útil en algunas situaciones, particularmente en el caso en el cual vale la pena almacenar un puntero extra para una instancia del objeto. Si esto no fuera - posible, el programador necesitaría recurrir a otros + posible, el programador necesitaría recurrir a otros artilugios para evitar este problema. - El propósito de tener un archivo de encabezado privado + El propósito de tener un archivo de encabezado privado extra para las estructuras privadas es permitir que las - clases derivadas usen esta información. Por supuesto, - una buena práctica de programación indicaría que debiera - proveerse de interfaces o métodos de acceso precisamente + clases derivadas usen esta información. Por supuesto, + una buena práctica de programación indicaría que debiera + proveerse de interfaces o métodos de acceso precisamente para que el programador no tenga que lidiar con estructuras privadas. Se debiera intentar alcanzar un - balance entre buena práctica y pragmatismo cuando se - crean estructuras privadas y métodos de acceso públicos. + balance entre buena práctica y pragmatismo cuando se + crean estructuras privadas y métodos de acceso públicos. - Podrían aparecer algunos problemas, por ejemplo, cuando - se ha enviado un versión del código y que está siendo + Podrían aparecer algunos problemas, por ejemplo, cuando + se ha enviado un versión del código y que está siendo ampliamente usado y se desea extenderlo. Hay dos soluciones para esto. - La primera opción es encontrar un campo puntero en la - estructura pública que pueda hacerse privada y + La primera opción es encontrar un campo puntero en la + estructura pública que pueda hacerse privada y reemplazar el puntero a la parte privada de la - estructura. Esto preserva el tamaño de la estructura - ya que, para los propósitos de GNOME, se puede - asumir que los punteros son todos del mismo tamaño. + estructura. Esto preserva el tamaño de la estructura + ya que, para los propósitos de GNOME, se puede + asumir que los punteros son todos del mismo tamaño. Se puede hacer que este campo apunte a la parte privada - de la estructura que será ubicada por la función que - originalmente creaba la estructura pública. Es + de la estructura que será ubicada por la función que + originalmente creaba la estructura pública. Es importante que este campo no sea llamado private, se trata de - una palabra reservada de C++ y creará problemas cuando + una palabra reservada de C++ y creará problemas cuando el archivo de encabezado sea usado desde programas - fuentes C++ — mejor llámalo + fuentes C++ — mejor llámalo priv. Por supuesto, este - tipo de cambios sólo funcionará si el antiguo campo - puntero solamente era usado para propósitos internos; - si los usuarios de la biblioteca habían tenido acceso - a dicho campo para cualquier propósito, será necesario - buscar otro campo o buscar una solución diferente. + tipo de cambios sólo funcionará si el antiguo campo + puntero solamente era usado para propósitos internos; + si los usuarios de la biblioteca habían tenido acceso + a dicho campo para cualquier propósito, será necesario + buscar otro campo o buscar una solución diferente. @@ -1580,16 +1580,16 @@ GtkObject y no hay campos punteros que puedan ser reemplazados, puedes usar la facilidad de datos de objetos de GTK+. Esto permite asociar punteros - a datos arbitrarios a objetos. Usa la función + a datos arbitrarios a objetos. Usa la función gtk_object_set_data() para adjuntar valores o estructuras a un objeto y cuando requieras usarlos - la función gtk_object_get_data() - permitirá recuperar dichos valores. Esto puede ser empleado + la función gtk_object_get_data() + permitirá recuperar dichos valores. Esto puede ser empleado para adjuntar una estructura privada a un objeto GTK+. - Esto no es tan eficiente como el enfoque anterior, pero podría - no importar para el dominio particular de la aplicación. Si - los datos serán accedidos frecuentemente, se pueden usar - quarks en vez de cadenas para agregar y obtenerlos a través + Esto no es tan eficiente como el enfoque anterior, pero podría + no importar para el dominio particular de la aplicación. Si + los datos serán accedidos frecuentemente, se pueden usar + quarks en vez de cadenas para agregar y obtenerlos a través de las funciones gtk_object_set_data_by_id() y gtk_object_get_data_by_id(), @@ -1602,12 +1602,12 @@ - Cómo modificar el código de otros + Cómo modificar el código de otros - GNOME es un proyecto de equipo, así las contribuciones de - código a programas de otras personas siempre son apreciadas. - Sigue los siguientes lineamientos cuando modifiques el código + GNOME es un proyecto de equipo, así las contribuciones de + código a programas de otras personas siempre son apreciadas. + Sigue los siguientes lineamientos cuando modifiques el código de otra persona. @@ -1617,19 +1617,19 @@ Etiqueta general - Siga el mismo estilo de indentación usado en el código - original. El código original perdurará durante más tiempo + Siga el mismo estilo de indentación usado en el código + original. El código original perdurará durante más tiempo que el que le pueda dedicar, mantener las - contribuciones consistentes respecto a la indentación - es más importante que forzar su estilo de indentación - en el código. + contribuciones consistentes respecto a la indentación + es más importante que forzar su estilo de indentación + en el código. Aunque sus parches pueden implementar una funcionalidad muy llamativa, es muy molesto para el - autor tener que reindentar el código antes de aplicar - un parche al código principal. Así, si el código + autor tener que reindentar el código antes de aplicar + un parche al código principal. Así, si el código original luce como: @@ -1646,7 +1646,7 @@ return total; } - entonces no agregues una función que luce como: + entonces no agregues una función que luce como: int sum_plus_cube_of_indices(int *values, int nvalues) { @@ -1660,33 +1660,33 @@ return total; } - En el segundo ejemplo, la indentanción y ubicación de las - llaves no coincide con el código original, no hay espacios - alrededor de los operadores y el código no se parecerá - al original. Sigue el estilo de programación del autor - original del programa y los parches que envías tendrán una mejor + En el segundo ejemplo, la indentanción y ubicación de las + llaves no coincide con el código original, no hay espacios + alrededor de los operadores y el código no se parecerá + al original. Sigue el estilo de programación del autor + original del programa y los parches que envías tendrán una mejor oportunidad de ser aceptados. - No repares errores con artilugios o hacks rápidos; repáralo - correctamente. Tampoco añadas características como hacks o - con código que no sea extensible; es mejor rehacer el - código original para que sea extensible y luego agrega - la nueva característica, utilizando el código como + No repares errores con artilugios o hacks rápidos; repáralo + correctamente. Tampoco añadas características como hacks o + con código que no sea extensible; es mejor rehacer el + código original para que sea extensible y luego agrega + la nueva característica, utilizando el código como estructura. - La limpieza de código siempre es bienvenida; si encuentras - trozos de código feos y sucios en GNOME, será muy - apreciado si envías parches que hagan el código más - agradable y fácil de mantener. + La limpieza de código siempre es bienvenida; si encuentras + trozos de código feos y sucios en GNOME, será muy + apreciado si envías parches que hagan el código más + agradable y fácil de mantener. - Como siempre, asegúrate de que el código que contribuye compila - sin ningún tipo de aviso, que tenga los prototipos correctos + Como siempre, asegúrate de que el código que contribuye compila + sin ningún tipo de aviso, que tenga los prototipos correctos y que sigan las directrices de este documento. @@ -1694,20 +1694,20 @@ - Cómo documentar los cambios + Cómo documentar los cambios - GNOME utiliza los archivos &ChangeLog; estándar de GNU para - documentar los cambios al código. Cada cambio que - efectúes a un programa debe ser - acompañado por una registro en el &ChangeLog;. Esto + GNOME utiliza los archivos &ChangeLog; estándar de GNU para + documentar los cambios al código. Cada cambio que + efectúes a un programa debe ser + acompañado por una registro en el &ChangeLog;. Esto permite a las personas leer la historia de cambios del programa de una manera sencilla. - Si usas &Emacs;, puede agregar las líneas al - &ChangeLog; presionando «C-x 4 a». + Si usas &Emacs;, puede agregar las líneas al + &ChangeLog; presionando «C-x 4 a». @@ -1738,36 +1738,36 @@ - Si agregas una nueva función a una biblioteca, escribe - la referencia necesaria y la documentación de programación. + Si agregas una nueva función a una biblioteca, escribe + la referencia necesaria y la documentación de programación. Puedes escribir una referencia a la documentacion - en línea usando el formato de comentarios descrito en + en línea usando el formato de comentarios descrito en gnome-libs/devel-docs/api-comment-style.txt. Si usas &Emacs;, gnome-libs/tools/gnome-doc/gnome-doc.el - provee un acelerador que puede ser empleado para añadir - una plantilla de documentación al programa. + provee un acelerador que puede ser empleado para añadir + una plantilla de documentación al programa. - Cómo actualizar en CVS + Cómo actualizar en CVS Si tienes acceso de escritura en el repositorio CVS de GNOME, - debes seguir algunas políticas adicionales. Ya que estás + debes seguir algunas políticas adicionales. Ya que estás trabajando en la copia maestra de los fuentes, debes tener especial cuidado. - Si estás reparando algo en un programa que está en el CVS - o si estás añadiendo una funcionalidad allí, y si no has - estado trabajando en dicho programa por un período largo + Si estás reparando algo en un programa que está en el CVS + o si estás añadiendo una funcionalidad allí, y si no has + estado trabajando en dicho programa por un período largo de tiempo, pregunta al autor original antes de aplicar - sus parches. Generalmente está bien formular estas + sus parches. Generalmente está bien formular estas preguntas en la lista de correo gnome-devel-list. @@ -1776,48 +1776,48 @@ Una vez que el autor del programa te indique como un ‘contribuyente frecuente’, puedes comenzar aplicar los parches sin previo consentimiento. Si - quieres aplicar una reorganización mayor del código, + quieres aplicar una reorganización mayor del código, debieras preguntar primero. - Algunos módulos en el CVS tienen rama estable y de + Algunos módulos en el CVS tienen rama estable y de desarrollo. Normalmente el desarrollo debiera ir en la rama HEAD en el CVS, y la rama estable debiera - mantenerse separadamente. Generalmente no se añaden - nuevas características a las rama estable; sólo + mantenerse separadamente. Generalmente no se añaden + nuevas características a las rama estable; sólo se reparan errores. Repara el error a la rama estable - y pregunta al autor principal sobre la política para + y pregunta al autor principal sobre la política para mezclar parches en la rama de desarrollo; algunos autores prefieren hacerlo por lotes, mientras hay otros que prefieren mezclarlos inmediatamente. - Si trabajas en una característica experimental que - podría estropear mucho código, crea una rama en el CVS - y realiza los cambios allí. No los mezcles en la rama + Si trabajas en una característica experimental que + podría estropear mucho código, crea una rama en el CVS + y realiza los cambios allí. No los mezcles en la rama principal de desarrollo hasta que te encuentres - razonablemente seguro que funcionará correctamente y que - se integrará bien dentro del resto del código. El uso de - una rama para trabajo en características experimentales - te permitirá evitar interrumpir el trabajo de otros + razonablemente seguro que funcionará correctamente y que + se integrará bien dentro del resto del código. El uso de + una rama para trabajo en características experimentales + te permitirá evitar interrumpir el trabajo de otros desarrolladores. Pregunte al autor principal antes de mezclar tu rama y traer sus cambios a la parte principal - del árbol. + del árbol. Como siempre, agrega un registro en el &ChangeLog; cuando realices un cambio. Algunos autores tienen la - política de rechazar, correctamente, los cambios que + política de rechazar, correctamente, los cambios que no tienen tal registro. - Algunas veces existen diferentes políticas para los módulos, - verifica si el módulo contiene un archivo - README.CVS. Si es así, lee ese archivo + Algunas veces existen diferentes políticas para los módulos, + verifica si el módulo contiene un archivo + README.CVS. Si es así, lee ese archivo antes de realizar cambios. @@ -1827,17 +1827,17 @@ Ramas y marcas - Tenemos una convención para nombrar las ramas y marcas o + Tenemos una convención para nombrar las ramas y marcas o puntos de una rama en el repositorio de CVS de GNOME. - Las marcas deben ser definidas después que se libera cada + Las marcas deben ser definidas después que se libera cada nueva version y deben ser de la forma - «MODULE_MAJOR_MINOR_MICRO», por ejemplo, - «GNOME_LIBS_1_0_53». Los puntos de una rama - deben ser de la forma «MODULE_BRANCH_ANCHOR», - como en «GNOME_LIBS_1_0_ANCHOR». Finalmente, - una rama raíz en este punto debiera ser de la forma - «module-branch», por ejemplo, - «gnome-libs-1-0». Usa esta convención cuando + «MODULE_MAJOR_MINOR_MICRO», por ejemplo, + «GNOME_LIBS_1_0_53». Los puntos de una rama + deben ser de la forma «MODULE_BRANCH_ANCHOR», + como en «GNOME_LIBS_1_0_ANCHOR». Finalmente, + una rama raíz en este punto debiera ser de la forma + «module-branch», por ejemplo, + «gnome-libs-1-0». Usa esta convención cuando crees marcas, puntos de una rama y ramas. @@ -1845,22 +1845,22 @@ - Políticas adicionales del CVS + Políticas adicionales del CVS CVS no proporciona un manera preconstruida para renombrar archivos o moverlos a otros directorios. Debiera planificar - cuidadosamente el árbol del repositorio de tal forma que evite + cuidadosamente el árbol del repositorio de tal forma que evite mover o renombrar archivos. En el caso que debas mover o renombrar un archivo en el CVS, - NO EJECUTES «cvs remove» - y luego «cvs add». Si lo haces, los archivos - «nuevos» perderán la capacidad de seguir su + NO EJECUTES «cvs remove» + y luego «cvs add». Si lo haces, los archivos + «nuevos» perderán la capacidad de seguir su historial de cambios, ya que desde el punto de vista de CVS - serán archivos completamente nuevos en su revisión + serán archivos completamente nuevos en su revisión inicial. Un objetivo del repositorio CVS de GNOME es poder seguir la historia de los fuentes de manera precisa desde el inicio. @@ -1869,14 +1869,14 @@ Por favor, pregunte al mantenedor del CVS, esto es, una persona conocida con acceso shell - a la máquina con CVS, para realizar la cirugía necesaria + a la máquina con CVS, para realizar la cirugía necesaria para mover los archivos por ti. Esto requiere conocimiento de la forma en que funciona CVS y debe ser - hecho muy cuidadosamente. La recuperación de un error de - «cvs add/remove» es una tarea muy desagradable; + hecho muy cuidadosamente. La recuperación de un error de + «cvs add/remove» es una tarea muy desagradable; Si mueves archivo en esta forma equivocada, un mantenedor - del CVS, quien tendrá que ir a reparar y realizar el trabajo - sucio, reclamará las penas del infierno. Así es que mejor + del CVS, quien tendrá que ir a reparar y realizar el trabajo + sucio, reclamará las penas del infierno. Así es que mejor pregunta por una persona que pueda mover los archivos por ti. @@ -1888,70 +1888,70 @@ - Cómo mantener un paquete + Cómo mantener un paquete Un mantenedor de paquete es una persona que se preocupa de liberar versiones, integrar cambios de otras personas y, en general, ser responsable de un paquete. Durante el - período de vida de un paquete, éste puede cambiar de - mantenedores, por ejemplo, una persona que pierde interés + período de vida de un paquete, éste puede cambiar de + mantenedores, por ejemplo, una persona que pierde interés o que ya no puede dedicarle tiempo suficiente como mantenedor. - En conformidad con los Estándares de programación de GNU, GNOME + En conformidad con los Estándares de programación de GNU, GNOME usa GNU Autoconf para manejar la portabilidad y GNU Automake - para crear makefiles. Automake hace especialmente fácil - construir paquetes correctos, así que si eres un mantenedor + para crear makefiles. Automake hace especialmente fácil + construir paquetes correctos, así que si eres un mantenedor de paquetes, debieras aprender como usarlo. Autoconf y - Automake tienen muchas áreas truculentas, así que siéntete + Automake tienen muchas áreas truculentas, así que siéntete libre de pedir ayuda en las listas de desarrollo de GNOME si tienes preguntas sobre la forma correcta de construir makefiles para tu paquete. - Un número de personas regularmente contribuye con traducciones - localizadas de los catálogos de mensajes en los paquetes de + Un número de personas regularmente contribuye con traducciones + localizadas de los catálogos de mensajes en los paquetes de GNOME. Para mantener las traducciones actualizadas tanto como sea posible, los mantenedores deben coordinarse con los - traductores para que estos últimos puedan actualizar las + traductores para que estos últimos puedan actualizar las traducciones a tiempo cuando se va a liberar una nueva - versión del paquete. Una buena forma de notificar a los + versión del paquete. Una buena forma de notificar a los traductores consiste en enviar un mensaje a gnome-i18n@gnome.org con suficientes - días de anticipación. Esto les permitirá actualizar sus + días de anticipación. Esto les permitirá actualizar sus respectivas traducciones a tiempo para puedan ser incluidas - en la siguiente versión liberada. + en la siguiente versión liberada. - ¿Por qué preocuparse por la pérdida de memoria? + ¿Por qué preocuparse por la pérdida de memoria? - Échale un vistazo a la lista de errores de Mozilla y una cosa es - clara: el nuevo código que entra a Mozilla no es (o no ha sido) - verificado suficientemente por pérdida de memoria y problemas + Échale un vistazo a la lista de errores de Mozilla y una cosa es + clara: el nuevo código que entra a Mozilla no es (o no ha sido) + verificado suficientemente por pérdida de memoria y problemas de acceso. - Las pérdidas de memoria son malas por varias razones: + Las pérdidas de memoria son malas por varias razones: - Se comerá el área de intercambio lentamente. A la larga tu - programa, o hasta tu máquina sucumbirán. + Se comerá el área de intercambio lentamente. A la larga tu + programa, o hasta tu máquina sucumbirán. Nadie quiere que su programa o biblioteca adquiera la - reputación de ser una porquería sólo porque uno ha sido un - vago. Déjaselo a las personas en Redmond. + reputación de ser una porquería sólo porque uno ha sido un + vago. Déjaselo a las personas en Redmond. @@ -1960,14 +1960,14 @@ Ocultan el mal uso de la memoria. Si olvidas liberar la memoria, no hay forma de atrapar las lecturas y escrituras a esos trozos de memoria. Si, posteriormente, - reparas la pérdida, una parte completamente distinta - del programa podría fallar. + reparas la pérdida, una parte completamente distinta + del programa podría fallar. - Cuando se usan verificadores automáticos de memoria, + Cuando se usan verificadores automáticos de memoria, nadie quiere ver 600 problemas, de los cuales 500 se encuentran en las bibliotecas de soporte. Lo que deseas saber es que estaba todo limpio antes que comenzara @@ -1977,7 +1977,7 @@ Este es uno de los problemas de Mozilla actualmente: - pierde memoria sin parar así que ¿cómo vas a saber si has + pierde memoria sin parar así que ¿cómo vas a saber si has contribuido al problema? @@ -1985,36 +1985,36 @@ - Algunos consejos contra la pérdida de memoria. + Algunos consejos contra la pérdida de memoria. - Usa «const» donde sea posible (para + Usa «const» donde sea posible (para punteros obviamente). - Si un argumento es «const», entonces - indudablemente la función llamada no liberará la memoria por + Si un argumento es «const», entonces + indudablemente la función llamada no liberará la memoria por ti. - Si el tipo de resultado de una función es - «const», entonces + Si el tipo de resultado de una función es + «const», entonces claramente no eres responsable por liberarlo. - Probablemente lo será para un resultado - distinto de «const» (que no sea un entero + Probablemente lo será para un resultado + distinto de «const» (que no sea un entero o algo similar). - Fíjate en que, desafortunadamente, esto no funciona muy bien + Fíjate en que, desafortunadamente, esto no funciona muy bien con los objetos que cuentan referencias. Funciona bien con cadenas. Dado que C usa llamadas por valor, no tiene sentido - aplicar «const» a tipos + aplicar «const» a tipos int, double y similares. @@ -2027,21 +2027,21 @@ - Si una función toma la propiedad de un objeto/referencia, - sé explícito acerca de ello. + Si una función toma la propiedad de un objeto/referencia, + sé explícito acerca de ello. - Indica siempre si el que llama a la función debiera + Indica siempre si el que llama a la función debiera liberar/desreferenciar los resultados. - Documenta cómo entregar la + Documenta cómo entregar la memoria: unref, free, g_free, ... @@ -2054,11 +2054,11 @@ - El proceso de cortado y pegado no mejora el código, al + El proceso de cortado y pegado no mejora el código, al contrario de lo que creen muchos programadores. Primero, - mira el código y si intenta producir muchas copias, quizás - necesite una función ayudante o nexo. + mira el código y si intenta producir muchas copias, quizás + necesite una función ayudante o nexo. @@ -2067,13 +2067,13 @@ Libera todo antes de salir. - Esto lleva tiempo, así que quizás debieras hacerlo - sólo dentro de una condición. + Esto lleva tiempo, así que quizás debieras hacerlo + sólo dentro de una condición. El motivo de este consejo es que los verificadores de memoria - toman tiempo en determinar entre una pérdida que tu conoces - y no te preocupan, y las otras pérdidas. + toman tiempo en determinar entre una pérdida que tu conoces + y no te preocupan, y las otras pérdidas. @@ -2091,33 +2091,33 @@ - Los punteros sueltos tienen la mala tendencia a ocultar pérdidas + Los punteros sueltos tienen la mala tendencia a ocultar pérdidas de memoria. - Ejecuta el nuevo código en un ciclo 1 millón de + Ejecuta el nuevo código en un ciclo 1 millón de veces. - Si pierdes memoria, lo sabrás — sólo sigue al proceso con - top en otra ventana. Podrías querer + Si pierdes memoria, lo sabrás — sólo sigue al proceso con + top en otra ventana. Podrías querer especificar a top el PID - del proceso con la opción -p. + del proceso con la opción -p. - Repáralo ahora, no después. + Repáralo ahora, no después. - No escribas una porquería de código; más temprano que - tarde te pesará. + No escribas una porquería de código; más temprano que + tarde te pesará.