--- a/programming-guidelines.xml Thu Sep 07 16:46:51 2006 -0400
+++ b/programming-guidelines.xml Fri Sep 08 10:46:48 2006 -0400
@@ -50,13 +50,23 @@
</address>
</affiliation>
</othercredit>
+ <othercredit>
+ <firstname>Lucas</firstname>
+ <surname>Vieites Fariña</surname>
+ <contrib>Revisión de la traducción al español</contrib>
+ <affiliation>
+ <address>
+ <email>lucas@asixinformatica.com</email>
+ </address>
+ </affiliation>
+ </othercredit>
</authorgroup>
<copyright>
<year>2000</year>
<holder>The Free Software Foundation</holder>
</copyright>
<copyright>
- <year>2004</year>
+ <year>2004—2006</year>
<holder>GNOME Foundation, respecto de la versión en español.</holder>
</copyright>
@@ -90,19 +100,19 @@
<para>
En este artículo intentamos presentar algunas sugerencias y
- guías que debería tener en cuenta cuando escriba código para
- el proyecto GNOME. Presentamos algunas de las políticas
+ 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 su
+ 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.
</para>
<para>
- Además de este documento, asegúrese de leer los Estándares de
+ Además de este documento, asegúrate de leer los Estándares de
Programación de GNU. Estos se encuentran disponibles en el
- nodo indo <filename>(Standards)</filename> en la documentación
+ nodo info <filename>(Standards)</filename> en la documentación
estándar de GNU.
</para>
</sect1>
@@ -120,14 +130,14 @@
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
+ 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.
</para>
<para>
Se tarda mucho tiempo en escribir software y supone una
- gran cantidad de trabajo. Es por esto que muchos
+ 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
gratificante contribuir a proyectos existentes, puesto que
@@ -179,7 +189,7 @@
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
- una número de supuestos y expectativas acerca del
+ 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.
</para>
@@ -192,7 +202,7 @@
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ísticas
+ 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
@@ -234,30 +244,30 @@
<title>Estilo de programación</title>
<para>
- «El estilo de programación» se refiere a la forma en
+ ‘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 obligamos el uso de ninguno de ellos. Lo más
+ 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
+ o una biblioteca — el código con un formato desordenado
no es aceptable debido a que es difícil de leer.
</para>
<para>
- Cuando se escribe un nuevo programa o biblioteca, siga un
+ Cuando escribas un nuevo programa o biblioteca, sigue un
estilo consistente de ubicación de llaves y de indentación.
- Si no tiene ninguna preferencia personal de estilo,
+ 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.
</para>
<para>
- Lea el nodo de info <filename>(Standards)Writing C</filename>
- en la documentación de GNU. Luego, obtenga el código fuente
- de Linux y lea el archivo
+ Lee el nodo de info <filename>(Standards)Writing C</filename>
+ en la documentación de GNU. Luego, obtén el código fuente
+ de Linux y lee el archivo
<filename>linux/Documentation/CodingStyle</filename>, e
- ignore los chistes de Linus. Estos dos documentos le darán
+ ignora los chistes de Linus. Estos dos documentos te darán
una buena idea de nuestras recomendaciones para el código de
GNOME.
</para>
@@ -269,7 +279,7 @@
<para>
Para el código del núcleo de GNOME preferimos el estilo
- de indentación del núcleo de Linux. Use tabuladores
+ de indentación del núcleo de Linux. Usa tabuladores
de 8 espacios para la indentación.
</para>
@@ -277,9 +287,9 @@
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 su código ordenado
+ 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
+ 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.
@@ -289,11 +299,11 @@
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 adelantes para entenderlo.
+ sin tener que desplazarse atrás y adelante para entenderlo.
</para>
<para>
- Si usa &Emacs;, entonces puedes seleccionar el estilo de
+ Si usas &Emacs;, entonces puedes seleccionar el estilo de
indentación del núcleo de Linux incluyendo en el
archivo <filename>.emacs</filename> lo siguiente:
@@ -301,8 +311,7 @@
(add-hook 'c-mode-common-hook
(lambda ()
(c-set-style "k&r")
- (setq c-basic-offset 8)))
- </programlisting>
+ (setq c-basic-offset 8)))</programlisting>
En los nuevos Emacs o con el nuevo cc-mode, puedes ser capaz
de hacerlo más simple con:
@@ -310,24 +319,22 @@
<programlisting>
(add-hook 'c-mode-common-hook
(lambda ()
- (c-set-style "linux")))
- </programlisting>
+ (c-set-style "linux")))</programlisting>
</para>
<para>
El estilo de indentación de GNU es el predeterminado para
&Emacs;, así que no es necesario agregar nada en el
archivo <filename>.emacs</filename> para habilitarlo.
- Si desea seleccionarlo explícitamente, sustituya
- «gnu» por «linux» en el ejemplo
- anterior.
+ Si deseas seleccionarlo explícitamente, sustituye
+ «gnu» por «linux» en el ejemplo anterior.
</para>
<para>
- Si usa &Vim;, entonces puede seleccionar el estilo
+ Si usas &Vim;, entonces puedes seleccionar el estilo
de indentación del núcleo de Linux incluyendo el
- siguiente fragmento en el
- archivo <filename>.vimrc</filename>:
+ siguiente fragmento en el archivo
+ <filename>.vimrc</filename>:
<programlisting>
set ts=8
@@ -336,25 +343,23 @@
augroup C
autocmd BufRead *.c set cindent
augroup END
-endif
- </programlisting>
+endif</programlisting>
</para>
<para>
- Como alternativa puede seleccionar el estilo de
+ Como alternativa puedes seleccionar el estilo de
indentación de GNU en &Vim; usando lo siguiente en
el archivo <filename>.vimrc</filename>:
<footnote>
<para>
- Gracias a Tomas Ögren por proporcionar este código.
+ Gracias a Tomas Ögren por proporcionar este código.
</para>
</footnote>:
<programlisting>
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
- </programlisting>
+augroup END</programlisting>
</para>
<note>
@@ -375,7 +380,7 @@
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
+ 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.
@@ -439,16 +444,16 @@
</para>
<para>
- Si está escribiendo una biblioteca, entonces puede necesitar
+ 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 <filename>libfoo.so</filename> pueden
requerir acceder a símbolos ubicados en el otro archivo,
pero se tiene la intención que éstos símbolos sean
utilizados desde los programas de usuario. En este caso,
- coloque una línea de subrayado antes del nombre de la
- función y haga que la primera palabra siga la convención
- estándar módulo/submódulo. Por ejemplo, podría tener
+ 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
<function>_foo_internal_frobnicate()</function>.
</para>
@@ -461,13 +466,13 @@
<para>
Es importante que las variables se nombren de manera
consistente. Por ejemplo, un módulo que manipula una
- lista puede elegir nombrar las variables que mantienen
+ lista puedes elegir nombrar las variables que mantienen
un puntero a la lista como «<symbol>l</symbol>»,
por elegancia y simplicidad. Sin embargo, es importante que
un módulo que manipula widgets y tamaños no use variables
llamadas «<symbol>w</symbol>» tanto para
- widgets y anchos («width») (como en valores de ancho/alto =>
- width/height); esto podría hacer que el código sea inconsistente
+ 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.
</para>
@@ -497,30 +502,29 @@
Aprender el uso correcto de la palabra reservada
<symbol>static</symbol>.
<emphasis>No</emphasis> declarar todos los símbolos como
- globales. Esto tiene la ventaja de que puede usar nombres
+ globales. Esto tiene la ventaja de poder usar nombres
más cortos dentro de las funciones en un sólo archivo
fuente, ya que no son globalmente visibles y por
- consiguiente no necesita emplear el prefijo
+ consiguiente no necesitas emplear el prefijo
módulo/submódulo.
</para>
<para>
- Aprenda el uso correcto de la palabra reservada
- <symbol>const</symbol>. Úsela consistentemente,
- así le permitirá al compilador que atrape muchos
+ Aprender el uso correcto de la palabra reservada
+ <symbol>const</symbol>. Úsala consistentemente,
+ así permitirás al compilador que atrape muchos
errores estúpidos.
</para>
<para>
- Si tiene 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ía usar el modificador
- const. Este avisará al usuario si intenta
+ no debe liberar, deberías usar el modificador
+ <symbol>const</symbol>. Este avisará al usuario si intenta
hacer alguna operación incorrecta, por ejemplo:
<programlisting>
-const char *gnome_mime_get_info (const char *info);
- </programlisting>
+const char *gnome_mime_get_info (const char *info);</programlisting>
El compilador avisará si el usuario intenta liberar
la cadena retornada. Esto puede atrapar muchos
@@ -528,29 +532,27 @@
</para>
<para>
- Si tiene «valores mágicos» en el programa o
- biblioteca, use macros que los definan en vez de usarlos
+ Si tienes «valores mágicos» en el programa o
+ biblioteca, usa macros que los definan en vez de usarlos
directamente en el código:
<programlisting>
/* Amount of padding for GUI elements */
#define GNOME_PAD 8
#define GNOME_PAD_SMALL 4
-#define GNOME_PAD_BIG 12
- </programlisting>
+#define GNOME_PAD_BIG 12</programlisting>
</para>
<para>
- Si tiene una lista de valores posibles para una variable,
- no use macros para ellas, use enum para darle
- un nombre de tipo --- esto permite disponer de nombres
- simbólicos en un depurador. Además, no use
- «int» para almacenar un valor enumerado; use
+ 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
el tipo enum. Esto le permite al compilador atrapar
- los errores por usted, 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:
<programlisting>
/* Shadow types */
@@ -562,12 +564,11 @@
GTK_SHADOW_ETCHED_OUT
} GtkShadowType;
-void gtk_frame_set_shadow_type (GtkFrame *frame, GtkShadowType type);
- </programlisting>
+void gtk_frame_set_shadow_type (GtkFrame *frame, GtkShadowType type);</programlisting>
</para>
<para>
- Si define un conjunto de valores para un campo de bits, haga
+ Si define un conjunto de valores para un campo de bits, haz
lo siguiente:
<programlisting>
@@ -579,8 +580,7 @@
GNOME_CANVAS_UPDATE_CLIP = 1 << 2,
GNOME_CANVAS_UPDATE_VISIBILITY = 1 << 3,
GNOME_CANVAS_UPDATE_IS_VISIBLE = 1 << 4
-};]]>
- </programlisting>
+};]]></programlisting>
Esto hace más fácil modificar la lista de valores y menos
propenso a error que especificando los valores a mano. También
@@ -588,28 +588,28 @@
</para>
<para>
- No escriba código ofuscado, intente que sea espartano.
- Para clarificar una expresión, no use más paréntesis que
- los necesarios. Use espacios antes de los paréntesis y
+ 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.
</para>
<para>
- No coloque hacks en el código. En vez de escribir un
- hack feo, reescriba 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.
</para>
<para>
- Asegúrese de que el código compila absolutamente sin ningún
- aviso del compilador. Esto le ayudará a atrapar errores
- estúpidos. Use 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.
</para>
<para>
- Dentro de GNOME puede usar la macro de Autoconf
+ Dentro de GNOME puedes usar la macro de Autoconf
<symbol>GNOME_COMPILE_WARNINGS</symbol> en el archivo
<filename>configure.in</filename>. Esto permitirá contar
con un buen conjunto de avisos del compilador de una manera
@@ -617,17 +617,17 @@
</para>
<para>
- Comente el código. Coloque comentarios antes de
- cada función para decir que hace. No diga cómo lo hace
+ 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
- pueda desear reescribirla hasta que sea fácil de
+ puedes desear reescribirla hasta que sea fácil de
entender.
</para>
<para>
- Cuando documente las funciones de la API de una biblioteca,
- siga las directrices indicadas en el archivo
+ Cuando documentes las funciones de la API de una biblioteca,
+ sigue las directrices indicadas en el archivo
<filename>gnome-libs/devel-docs/api-comment-style.txt</filename>.
Esto permite que el código fuente pueda proporcionar documentación
en línea, que posteriormente se extrae mediante el sistema
@@ -644,7 +644,7 @@
Se construye GNOME en muchas plataformas diferentes.
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ándar de
+ así que se puede asumir que los servicios estándares de
Unix estarán disponibles.<footnote>
<para>
¿Servicios estándar de Unix? Por supuesto que estamos
@@ -654,29 +654,28 @@
</para>
<para>
- Recuerde que el mundo no es su propio equipo con GNU/Linux;
+ Recuerda que el mundo no es tu propio equipo con GNU/Linux;
las gente realmente usa otros tipos de máquinas.
</para>
<para>
- Intente no usar extensiones específicas de
+ Intenta no usar extensiones específicas de
<application>GCC</application> debido a que éstas no
- funcionarán con otros compiladores. Si realmente debe
- hacer uso de tal cosa, vea la forma en que se hace
+ funcionarán con otros compiladores. Si realmente debes
+ hacer uso de tal cosa, ve la forma en que se hace
en <application>Glib</application> con el conjunto de
- macros G_GNUC; asegúrese también de incluir código
- que funcione con compiladores ISO C. Si sólo tiene
- disponible <application>GCC</application>, aprenda a usar
+ macros G_GNUC; asegúrate también de incluir código
+ que funcione con compiladores ISO C. Si sólo tienes
+ disponible <application>GCC</application>, aprende a usar
las opciones <option>-ansi -pedantic</option> que
permiten probar código sospechoso.
</para>
<para>
- Recuerde que algunas plataformas no disponen de
+ Recuerda que algunas plataformas no disponen de
<application>GCC</application> o que
<application>GDB</application> puede ser inusable en ellos,
- y se querrán usar otros compiladores y
- depuradores.
+ y se querrán usar otros compiladores y depuradores.
</para>
</sect3>
@@ -686,12 +685,12 @@
<title>Tópicos relacionados con GTK+</title>
<para>
- GTK+ permite hacer mucha magia y ofuscación con manipuladores
- de señas, pasar cerraduras y conjuntos de datos. Si se
- encuentra hadiendo muchos
- <symbol>gtk_object_set_data()</symbol> en un mismo lugar,
- o pasado estados de forma extraña a través de manejadores de
- señales, reescriba el código. Si necesita adjuntar muchos
+ GTK+ permite hacer mucha magia y ofuscación con manejadores
+ de señal, pasar cerraduras y conjuntos de datos. Si te
+ encuentras utilizando muchos
+ <function>gtk_object_set_data()</function> 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
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.
@@ -716,11 +715,11 @@
<para>
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
+ 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 su código
+ 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 fiable que se ejecute correctamente
+ y merecen un software confiable que se ejecute correctamente
y que no se caiga.
</para>
@@ -731,7 +730,7 @@
<para>
<!-- FIXME: Buscar un mejor termino para "assertion" -->
- Utilice las macros de aserción de Glib para asegurarse de
+ 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á
mucho menos tiempo en el depurado si se emplean de forma
@@ -739,7 +738,7 @@
</para>
<para>
- Inserte verificaciones de sanidad en el código en puntos
+ 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
@@ -756,8 +755,8 @@
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ía usarlas libremente; a cambio podrá
- localizar errores muy rápidamente y ocupará 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.
</para>
@@ -769,8 +768,8 @@
<variablelist>
<varlistentry>
- <term><symbol>g_return_if_fail
- (condición)</symbol></term>
+ <term><function>g_return_if_fail
+ (condición)</function></term>
<listitem>
<para>
Retorna desde la línea actual de la función si la
@@ -780,8 +779,8 @@
</varlistentry>
<varlistentry>
- <term><symbol>g_return_val_if_fail (condición,
- valor)</symbol></term>
+ <term><function>g_return_val_if_fail (condición,
+ valor)</function></term>
<listitem>
<para>
Retorna el <symbol>valor</symbol> indicado desde
@@ -802,7 +801,7 @@
<variablelist>
<varlistentry>
- <term><symbol>g_assert (condición)</symbol></term>
+ <term><function>g_assert (condición)</function></term>
<listitem>
<para>
Aborta el programa si la <symbol>condición</symbol>
@@ -812,7 +811,7 @@
</varlistentry>
<varlistentry>
- <term><symbol>g_assert_not_reached ()</symbol></term>
+ <term><function>g_assert_not_reached ()</function></term>
<listitem>
<para>
Aborta el programa si se llama a la macro.
@@ -825,24 +824,24 @@
<para>
Estas funciones debieran emplearse para imponer
precondiciones en el código y verificar su corrección
- --- piense en ellas como verificaciones de sanidad
- en los programas. Debiera usarlas libremente como
+ — piensa en ellas como verificaciones de sanidad
+ en los programas. Debieras usarlas libremente como
asistencia para atrapar los errores rápidamente; una
vez que el programa se encuentre completamente depurado,
- puede compilarlo con estas macros deshabilitadas y así
- evitar añadirle sobrecarga en el momento de ejecutarlos.
+ puedes compilarlo con estas macros deshabilitadas y así
+ evitar añadirle sobrecarga al momento de ejecutarlos.
</para>
<para>
- Las macros <symbol>g_return_*()</symbol> debieran
+ Las macros <function>g_return_*()</function> debieran
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
- <symbol>void</symbol>), debiera usar
- <symbol>g_return_if_fail()</symbol>. En caso contrario,
- debiera usar <symbol>g_return_val_if_fail()</symbol>
- para retornar un valor «seguro». Cuando
+ <symbol>void</symbol>), debieras usar
+ <function>g_return_if_fail()</function>. En caso contrario,
+ debiera usar <function>g_return_val_if_fail()</function>
+ 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
@@ -853,27 +852,27 @@
</para>
<para>
- La macro <symbol>g_assert()</symbol> debiera usarse para
+ La macro <function>g_assert()</function> 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,
- <symbol>g_assert()</symbol> producirá en mensaje de error
+ <function>g_assert()</function> 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. Debiera usar esta macro para
- asegurarse de que el programa o biblioteca está usando
+ estado inconsistente. Debieras usar esta macro para
+ asegurarte de que el programa o biblioteca está usando
valores internos sanos.
</para>
<para>
- La macro <symbol>g_assert_not_reached()</symbol> se
+ La macro <function>g_assert_not_reached()</function> se
usa para marcar el lugar en el código que nunca
- debiera producirse. Por ejemplo, si tiene una
- cláusula <symbol>switch</symbol> y piensa que maneja
+ debiera producirse. Por ejemplo, si tienes una
+ cláusula <symbol>switch</symbol> y piensas que manejas
todos los valores posibles en las etiquetas
- <symbol>case</symbol>, entonces debiera colocar
- <symbol>g_assert_not_reached()</symbol> en la
- etiqueta <symbol>default</symbol> para asegurarse de que
+ <symbol>case</symbol>, entonces debieras colocar
+ <function>g_assert_not_reached()</function> en la
+ etiqueta <symbol>default</symbol> 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
incorrecto).
@@ -882,8 +881,8 @@
<para>
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. Úselos
- frecuentemente y encontrará muchos errores más
+ el programa alcanza un estado incosistente. Úsalos
+ frecuentemente y encontrarás muchos errores más
fácilmente.
</para>
</sect2>
@@ -894,37 +893,36 @@
<title>Tópicos relacionados con GTK+</title>
<para>
- Sea cuidadoso cuando escriba manejadores de eventos
- --- asegurése de que los eventos son manipuladas en
+ 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
- correctos. Esto es muy importante. Recuerde que no
+ correctos. Esto es muy importante. Recuerda que no
todos los prototipos de manejadores de señal se parecen
a lo siguiente:
<programlisting>
-static void my_handler (GtkWidget *widget, gpointer data);
- </programlisting>
+static void my_handler (GtkWidget *widget, gpointer data);</programlisting>
Por ejemplo, los manejadores de eventos tienen un parámetro
- extra de evento y retornan <symbol>gint</symbol>. Vea los
- archivos de encabezado de GTK+ cuando necesite verificarlo.
+ extra de evento y retornan <symbol>gint</symbol>. Revisa los
+ archivos de encabezado de GTK+ cuando necesites verificarlo.
</para>
<para>
- Asegúrese de que el programa trata de una forma apropiada
- todas las acciones generadas por el usuario. Recuerde
+ 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; téngalo
- presente y escriba el código necesario para manejar esta
+ momento a través del administrador de ventanas; tenlo
+ presente y escribe el código necesario para manejar esta
situación.
</para>
<para>
- Si verifica los modificadores de teclas con una máscara
+ Si verificas los modificadores de teclas con una máscara
de estado de eventos, por ejemplo,
<keycombo><keycap>Control</keycap><keycap>F10</keycap></keycombo>
- haga esto:
+ escribe lo siguiente:
<programlisting>
guint modifiers;
@@ -934,14 +932,12 @@
if (event->keysym == GDK_F10
&& (event->state & modifiers) == GDK_CONTROL_MASK) {
do_something ();
- }
- </programlisting>
+ }</programlisting>
- Esto es necesario; si en vez de lo anterior hace:
+ Esto es necesario; si en vez de lo anterior escribes:
<programlisting>
- if (event->keysym == GDK_F10 && event->state == GDK_CONTROL_MASK)
- </programlisting>
+ if (event->keysym == GDK_F10 && event->state == GDK_CONTROL_MASK)</programlisting>
entonces el programa no funcionará correctamente si el
usuario tiene, por ejemplo, activada la tecla
@@ -971,36 +967,36 @@
<para>
Es importante entender las vistas y mapas de colores si
- va a escribir código que crea ventanas y pixmaps por sus
+ 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.
</para>
<para>
- <!-- FIXME: traducir -->
- In general, you just need to remember that the visual and
- colormap for a drawable must match the ones of another
- drawable if you want to copy an area from the first drawable
- into the second one. If they are not the same, you will get
- a BadMatch error from X and you application will most likely
- abort.
+ 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.
</para>
<para>
- If you create a graphics context (GC) and share it to paint
- onto several drawables, make sure all of them have the same
- visual and colormap for which the GC was defined. The same
- applies if you want to copy an area from a pixmap to a
- window; both must have the same visual and colormap
+ 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
+ pixmap a una ventana; ambos deben tener la misma vista y mapa
+ de colores.
</para>
<para>
- Si no está seguro de que su código lo hace correctamente, pregunte
- 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 personas
- sabrá como arreglar el problema y le dirá al respecto.
+ 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.
</para>
</sect3>
</sect2>
@@ -1011,37 +1007,39 @@
<title>Temas relacionados con Unix</title>
<para>
- Verifique los valores de retorno de <emphasis>todas</emphasis>
- las llamas al sistema que el programa realice. Recuerde
+ Verifica los valores de retorno de <emphasis>todas</emphasis>
+ las llamadas al sistema que el programa realice. Recuerda
que muchas de las llamadas al sistema pueden ser
- interrumpidas (por ejemplo, la llamada retornar -1 y
- errno será definido a EINTR) y deben reiniciarse.
+ interrumpidas (por ejemplo, la llamada retorna
+ <symbol>-1</symbol> y <symbol>errno</symbol> será definido a
+ <symbol>EINTR</symbol>) y deben reiniciarse.
</para>
<para>
- No asuma, por ejemplo, que la función
+ No asumas, por ejemplo, que la función
<function>write(2)</function> escribirá el buffer completo
- de una vez; tiene que verificar el valor de retorno, el cual
- indica el número de bytes escritos e intente nuevamente
- hasta que sea cero. Si el valor de retorno es -1, recuerde
+ de una vez; tienes que verificar el valor de retorno, el cual
+ indica el número de bytes escritos e intenta nuevamente
+ hasta que sea cero. Si el valor de retorno es
+ <symbol>-1</symbol>, recuerda
verificar el valor de errno y manejar el error
apropiadamente.
</para>
<para>
Si la aplicación llama a la función <function>fork(2)</function>
- sin llamar a <function>execve(2)</function>, recuerde que
+ sin llamar a <function>execve(2)</function>, recuerda que
el proceso hijo no puede hacer llamadas X. Normalmente se
puede diagnosticar este problema a través de un oscuro
mensaje de error de Xlib.
</para>
<para>
- Lea el libro «Advanced programming in the Unix
- environment», de Stevens, para aprender acerca de
- todos estos temas y asegúrese de que sus programas usan
- la API de Unix de forma correcta. Si no desea asegurarse
- del uso correcto de las llamadas Unix, pregunte en las
+ 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.
</para>
</sect2>
@@ -1055,25 +1053,25 @@
<para>
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 sus
+ Intentaremos indicar las situaciones más comunes donde tus
programas deben interesarse por la seguridad.
</para>
<para>
Es muy fácil crear hoyos de seguridad a través de la creación
incorrecta de archivos temporales en <filename>/tmp</filename>.
- Debe garantizar que los archivos que usará no existen al
- momento de su creación. Usando un nombre de archivo «único»
- e «impredecible» no es suficiente; debe garantizar que el archivo
+ 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
- que determina el nombre y el tiempo en que es efectivamente
+ 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
sobreescribir).
</para>
<para>
- Afortunadamente, esto es fácil de hacer. Use el siguiente trozo
+ Afortunadamente, esto es fácil de hacer. Usa el siguiente trozo
de código:
<programlisting>
@@ -1089,8 +1087,7 @@
fd = open (filename, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 0600);
free (filename);
- } while (fd == -1);
- </programlisting>
+ } while (fd == -1);</programlisting>
Recuerde liberar <symbol>filename</symbol> usando la función
<function>free()</function> y llamar a las funciones
@@ -1101,24 +1098,24 @@
</para>
<para>
- Si desea usar las biblioteca estándar de E/S, puede usar la
+ Si deseas usar la biblioteca estándar de E/S, puede usar la
función <function>fdopen()</function> para transformar el
- descriptor de archivo en <symbol>FILE *</symbol>, o puede
- usar la <function>tmpfile()</function> para hacerlo en un
- solo paso.
+ descriptor de archivo en <symbol>FILE *</symbol>, o puedes
+ usar la función <function>tmpfile()</function> para hacerlo
+ en un solo paso.
</para>
<para>
- Intente no usar buffers de tamaño fijo. Los buffers de tamaño
+ 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
- debe usar buffers de tamaño fijo para cadenas, use la función
+ debes usar buffers de tamaño fijo para cadenas, usa la función
<function>g_snprintf()</function> para especificar el tamaño
máximo del buffer.
</para>
<para>
- Glib proporciona la muy conveniente función
+ Glib proporciona la, muy conveniente, función
<function>g_strdup_printf()</function>, la cual funciona como
<function>sprintf()</function> pero automáticamente
localizará un buffer con el tamaño correcto. El valor de retorno
@@ -1129,45 +1126,46 @@
</para>
<para>
- Si desea concatenar un grupo de cadenas, puede usar la función
+ Si deseas concatenar un grupo de cadenas, puedes usar la función
<function>g_strconcat()</function>, la cual recibe una lista
- variables de cadenas y un puntero a NULL como último argumento.
+ variable de cadenas y un puntero a <symbol>NULL</symbol>
+ como último argumento.
</para>
<para>
- <emphasis>Bajo ninguna circunstancia</emphasis> cree un
+ <emphasis>Bajo ninguna circunstancia</emphasis> crees un
programa GTK+ con setuid root. Las bibliotecas de GTK+ y
GNOME son grandes y complejas y no han tenido auditorías
- de seguridad. En cualquier caso, no debiera querer que
+ de seguridad. En cualquier caso, no debieras querer que
una pieza tan grande código sea setuid root. Si definitivamente
- requiere usar privilegios de root para algo, escriba un
+ requieres usar privilegios de root para algo, escribe un
programa que sea la interfaz de usuario como un proceso
- normal, sin privilegios y cree un programa de ayuda que
+ normal, sin privilegios y crea un programa nexo que
tenga setuid y se encargue de realizar la operaciones
- «peligrosas». Además, notifique a las listas
- de correo de desarrollo de GNOME indicando que requiere
- que alguien realice una auditoría de seguridad a su
- programa de ayuda.
+ «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
+ programa nexo.
</para>
<para>
- En general, si no está seguro si puede crear un riesgo de
- seguridad, pregunte en la listas de correo de desarrollo
+ En general, si no estás seguro si puedes crear un riesgo de
+ seguridad, pregunte en las listas de correo de desarrollo
de GNOME.
</para>
<para>
- Puede leer más sobre temas de seguridad que debiera encontrar
- cuando programe una aplicación Unix en el documento
+ Puedes leer más sobre temas de seguridad que debieras encontrar
+ cuando programes una aplicación Unix en el documento
<ulink URL="http://www.fish.com/security/murphy.html">«Murphy's
Law and Computer Security»</ulink>, de Wietse Wenema.
Hay otros documentos de seguridad en <ulink
URL="http://www.fish.com/security">el sitio fish.com</ulink>
- que podría encontrar interesante.
+ que podrías encontrar interesante.
</para>
<para>
- Puede encontrar muchas otras guías útiles para escribir programas
+ Puedes encontrar muchas otras guías útiles para escribir programas
seguros en <ulink
url="http://www.dwheeler.com/secure-programs">«Secure
Programming for Linux and Unix HOWTO»</ulink>.
@@ -1180,43 +1178,43 @@
<title>Rendimiento</title>
<para>
- No lea esta sección hasta que esté seguro de que su programa está
- correcto, por ejemplo, cuando esté seguro de que funciona
+ 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.
</para>
<para>
- Si quiere optimizar su programa, el primer paso es determinar
+ 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 adelante la optimización si no tiene
- una idea clara sobre donde está el problema. Podría terminar
+ 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ía terminar ofuscando
+ 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.
</para>
<para>
Un código sencillo es bueno porque es fácil de entender y
- mantener. Si puede escribir código simple que además sea
- potente y rápido, tanto mejor. Si tiene un trozo de código
- inteligente pero que no es fácil de seguir, entonces documéntelo
+ 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.
</para>
<para>
- No escriba código que sea difícil de leer y mantener por el
- sólo hecho de hacerlo más rápido. En cambio prefiera un algoritmo
- agradable y claro e impleméntelo 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.
</para>
<para>
Hacer un buen trabajo en el caso general es a menudo mejor que
- tener muchos casos especiales. Sólo provea casos especiales
+ tener muchos casos especiales. Sólo provee casos especiales
cuando se han identificado puntos débiles en el programa.
</para>
@@ -1225,27 +1223,27 @@
<sect2 id="list">
<title>Administración de listas en Glib</title>
<para>
- Evite emplear construcciones que terminen ralentizando
- los algoritmos. Si usa
+ Evita emplear construcciones que terminen ralentizando
+ los algoritmos. Si usas
<function>g_list_insert_sorted()</function> o
<function>g_list_append()</function> sin ningún cuidado,
- fácilmente puede tener un algoritmo que se ejecuta en
+ fácilmente puedes tener un algoritmo que se ejecuta en
tiempo proporcional a O(n<superscript>2</superscript>).
- Normalmente puede crear listas hacia atrás, usando
+ Normalmente puedes crear listas hacia atrás, usando
<function>g_list_prepend()</function>, e invirtiéndola
- cuando haya terminado usando
+ cuando hayas terminado usando
<function>g_list_reverse()</function>. Esta es una
- operación O(n). Y si necesita una lista ordenada, puede
+ operación O(n). Y si necesitas una lista ordenada, puedes
crearla de la misma forma (hacia atrás) y una vez terminado,
usar <function>g_list_sort()</function>.
</para>
<para>
- Si necesita una lista ordenada en todo momento, puede ser
+ Si necesitas una lista ordenada en todo momento, puede ser
mejor emplear un estructura de árbol o un híbrido
- lista/árbol. Si necesita construir una lista añadiendo
- nodos a ella, mantenga un puntero al final de la lista
- y vaya cambiándola según sea apropiado; esto le permitira
+ 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.
</para>
</sect2>
@@ -1259,13 +1257,13 @@
<para>
Se pretende que GNOME pueda ejecutarse en distintas localidades
y lenguajes, y los programas debieran tener esto en cuenta. No
- tiene que localizar los programas, sólo debe permitir que éstos
+ tienes que localizar los programas, sólo debes permitir que éstos
sean traducibles y localizables.
</para>
<para>
- Debe recordar que los diferentes idiomas humanos tienen diferentes
- gramáticas, así que no debiera suponer la forma de estructurar
+ Debes recordar que los diferentes idiomas humanos tienen diferentes
+ 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.
</para>
@@ -1274,7 +1272,7 @@
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, intente usar
+ los idiomas. En vez de concatenar, intenta usar
<function>g_strdup_printf()</function>, por ejemplo:
<programlisting>
@@ -1286,15 +1284,14 @@
/* Una mejor forma */
char *message = g_strdup_printf (_("Hello, %s, would you like fries with that?"),
- name);
- </programlisting>
+ name);</programlisting>
Esto permitirá al traductor mover %s donde corresponda según
lo requiera la gramática del idioma en el cual trabaja.
</para>
<para>
- Recuerdo que no todos los idiomas forman los plurales añadiendo
+ 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,
@@ -1307,8 +1304,7 @@
/* Una mejor forma */
printf ((num_monkeys > 1)
? _("%d happy monkeys bouncing on the bed."),
- : _("%d happy monkey bouncing on the bed."));
- </programlisting>
+ : _("%d happy monkey bouncing on the bed."));</programlisting>
Se requiere de esta forma ya que el plural se forma de
distintas maneras en distintos idiomas, y la estructura
@@ -1316,19 +1312,19 @@
</para>
<para>
- Si el programa muestra fechas u horas, use la función
+ Si el programa muestra fechas u horas, usa la función
<function>strftime()</function> 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, recuerde que en
+ 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.
</para>
<para>
- Si el programa usa medidas, asegúrese de permitir tanto
+ Si el programa usa medidas, asegúrate de permitir tanto
el sistema métrico decimal como el sistema imperial (o anglosajón).
</para>
</sect1>
@@ -1346,7 +1342,7 @@
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
- puede realizar tantos cambios como lo necesiten.
+ puedes realizar tantos cambios como se necesiten.
</para>
<para>
@@ -1356,8 +1352,8 @@
(tanto los tipos como su significado), el significado de los
valores enumerados y la semántica de los archivos que la
biblioteca crea. Mantener compatibilidad binaria significa que
- estas interfaces no cambiarán. Puede añadir nuevas interfaces
- sin romper la compatibilidad binaria, pero no puede cambiar
+ 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
correctamente.
</para>
@@ -1434,8 +1430,8 @@
</para>
<para>
- Por ejemplo, imagine que se crea el objeto GnomeFrob.
- La implementación del widget sera dividido en tres
+ Por ejemplo, imagina que se crea el objeto GnomeFrob.
+ La implementación del widget será dividido en tres
archivos:
<table>
@@ -1461,11 +1457,11 @@
<row>
<entry><filename>gnome-frob-private.h</filename></entry>
<entry>Datos privados de la implementación de GnomeFrob.
- Debiera querer usar esto si planea compartir los
+ Debieras querer usar esto si planea compartir los
datos privados a través de varios archivos C. Si
- limita el uso de la información privada a sólo un
+ 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 logrará
+ estructura en el archivo de implementación se logrará
el mismo efecto.</entry>
</row>
</tbody>
@@ -1489,9 +1485,7 @@
} GnomeFrob;
GnomeFrob *gnome_frob_new (void);
-void gnome_frob_frobate (GnomeFrob *frob);
- </programlisting>
-
+void gnome_frob_frobate (GnomeFrob *frob);</programlisting>
</example>
<example>
@@ -1500,8 +1494,7 @@
<programlisting>
typedef struct {
gboolean frobbed;
-} GnomeFrobPrivate;
- </programlisting>
+} GnomeFrobPrivate;</programlisting>
</example>
<example>
@@ -1514,8 +1507,7 @@
g_return_if_fail (GNOME_IS_FROB (frob));
frob->priv->frobbed = TRUE;
-}
- </programlisting>
+}</programlisting>
</example>
Fíjese en el uso de prototipos de estructura: esto permite que
@@ -1564,7 +1556,7 @@
<structfield>private</structfield>, se trata de
una palabra reservada de C++ y creará problemas cuando
el archivo de encabezado sea usado desde programas
- fuentes C++ — mejor llámelo
+ fuentes C++ — mejor llámalo
<structfield>priv</structfield>. Por supuesto, este
tipo de cambios sólo funcionará si el antiguo campo
puntero solamente era usado para propósitos internos;
@@ -1576,11 +1568,11 @@
<para>
Si la estructura original fue derivada de
<structname>GtkObject</structname> y no hay campos punteros
- que puedan ser reemplazados, puede usar la facilidad
+ que puedan ser reemplazados, puedes usar la facilidad
de datos de objetos de GTK+. Esto permite asociar punteros
- a datos arbitrarios a objetos. Use la función
+ a datos arbitrarios a objetos. Usa la función
<function>gtk_object_set_data()</function> para adjuntar
- valores o estructuras a un objeto y cuando requiera usarlos
+ valores o estructuras a un objeto y cuando requieras usarlos
la función <function>gtk_object_get_data()</function>
permitirá recuperar dichos valores. Esto puede ser empleado
para adjuntar una estructura privada a un objeto GTK+.
@@ -1605,7 +1597,7 @@
<para>
GNOME es un proyecto de equipo, así las contribuciones de
código a programas de otras personas siempre son apreciadas.
- Siga los siguientes lineamientos cuando modifique el código
+ Sigue los siguientes lineamientos cuando modifiques el código
de otra persona.
</para>
@@ -1628,7 +1620,7 @@
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
- original luce como
+ original luce como:
<programlisting>
int
@@ -1642,10 +1634,9 @@
total += values[i] + i * i;
return total;
-}
- </programlisting>
+}</programlisting>
- entonces no agregue una función que luce como
+ entonces no agregues una función que luce como:
<programlisting>
int sum_plus_cube_of_indices(int *values, int nvalues) {
@@ -1657,37 +1648,36 @@
total+=values[i]+i*i*i;
return total;
-}
- </programlisting>
+}</programlisting>
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. Siga el estilo de programación del autor
- original del programa y los parches que envíe tendrán una mejor
+ 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.
</para>
<para>
- No repare errores con hacks rápidos o artilugios; repárelo
- correctamente. Tampoco añada características como hacks o
+ 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 agregue
+ código original para que sea extensible y luego agrega
la nueva característica, utilizando el código como
estructura.
</para>
<para>
- La limpieza de código siempre es bienvenida; si encuentra
+ La limpieza de código siempre es bienvenida; si encuentras
trozos de código feos y sucios en GNOME, será muy
- apreciado si envía parches que hagan el código más
+ apreciado si envías parches que hagan el código más
agradable y fácil de mantener.
</para>
<para>
- Como siempre, asegúrese de que el código que contribuye compila
+ 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 siga las directrices de este documento.
+ y que sigan las directrices de este documento.
</para>
</sect2>
@@ -1699,21 +1689,21 @@
<para>
GNOME utiliza los archivos &ChangeLog; estándar de GNU para
documentar los cambios al código. Cada cambio que
- efectúe a un programa <emphasis>debe</emphasis> ser
+ efectúes a un programa <emphasis>debe</emphasis> 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.
</para>
<para>
- Si usa &Emacs;, puede agregar las líneas al
+ Si usas &Emacs;, puede agregar las líneas al
&ChangeLog; presionando «C-x 4 a».
</para>
<note>
<para>
- Si conoce la forma de realizarlos para otros editores
- populares, agradeceremos que nos lo haga saber para
+ Si conoces la forma de realizarlos para otros editores
+ populares, agradeceremos que nos lo hagas saber para
expandir este documento.
</para>
</note>
@@ -1734,17 +1724,16 @@
1999-04-18 Johnny Grep <grep@foobar.com>
- * baz.c (ugly_function): Beautified by using a helper function.
- </programlisting>
+ * baz.c (ugly_function): Beautified by using a helper function.</programlisting>
</para>
<para>
- Si agrega una nueva función a una biblioteca, escriba
+ Si agregas una nueva función a una biblioteca, escribe
la referencia necesaria y la documentación de programación.
- Puede escribir una referencia a la documentacion
+ Puedes escribir una referencia a la documentacion
en línea usando el formato de comentarios descrito en
<filename>gnome-libs/devel-docs/api-comment-style.txt</filename>.
- Si usa &Emacs;,
+ Si usas &Emacs;,
<filename>gnome-libs/tools/gnome-doc/gnome-doc.el</filename>
provee un acelerador que puede ser empleado para añadir
una plantilla de documentación al programa.
@@ -1757,28 +1746,28 @@
<title>Cómo actualizar en CVS</title>
<para>
- Si tiene acceso de escritura en el repositorio CVS de GNOME,
- debe seguir algunas políticas adicionales. Ya que está
- trabajando en la copia maestra de los fuentes, debe tener
+ Si tienes acceso de escritura en el repositorio CVS de GNOME,
+ debes seguir algunas políticas adicionales. Ya que estás
+ trabajando en la copia maestra de los fuentes, debes tener
especial cuidado.
</para>
<para>
- Si está reparando algo en un programa que está en el CVS
- o si está añadiendo una funcionalidad allí, y si no ha
+ 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, pregunte al autor original antes de aplicar
+ de tiempo, pregunta al autor original antes de aplicar
sus parches. Generalmente está bien formular estas
preguntas en la lista de correo
<filename>gnome-devel-list</filename>.
</para>
<para>
- Una vez que el autor del programa lo indique como un
- «contribuyente frecuente», puede comenzar
+ Una vez que el autor del programa te indique como un
+ ‘contribuyente frecuente’, puedes comenzar
aplicar los parches sin previo consentimiento. Si
- quiere aplicar un reorganización mayor del código,
- debiera preguntar primero.
+ quieres aplicar una reorganización mayor del código,
+ debieras preguntar primero.
</para>
<para>
@@ -1787,38 +1776,38 @@
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
- se reparan errores. Repare el error a la rama estable
- y pregunte al autor principal sobre la política para
+ se reparan errores. Repara el error a la rama estable
+ 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.
</para>
<para>
- Si trabaja en una característica experimental que
- podría estropear mucho código, cree una rama en el CVS
- y realice los cambios allí. No los mezcle en la rama
- principal de desarrollo hasta que se encuentre
+ 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
- le permitirá evitar interrumpir el trabajo de otros
+ te permitirá evitar interrumpir el trabajo de otros
desarrolladores. Pregunte al autor principal antes de
- mezclar su rama y traer sus cambios a la parte principal
+ mezclar tu rama y traer sus cambios a la parte principal
del árbol.
</para>
<para>
- Como siempre, agrege un registro en el &ChangeLog;
- cuando realice un cambio. Algunos autores tienen la
+ Como siempre, agrega un registro en el &ChangeLog;
+ cuando realices un cambio. Algunos autores tienen la
política de rechazar, correctamente, los cambios que
no tienen tal registro.
</para>
<para>
Algunas veces existen diferentes políticas para los módulos,
- verifique si el módulo contiene un archivo
- <filename>README.CVS</filename>. Si es así, lea ese archivo
+ verifica si el módulo contiene un archivo
+ <filename>README.CVS</filename>. Si es así, lee ese archivo
antes de realizar cambios.
</para>
@@ -1838,8 +1827,8 @@
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». Use esta convención cuando
- cree marcas, puntos de una rama y ramas.
+ «gnome-libs-1-0». Usa esta convención cuando
+ crees marcas, puntos de una rama y ramas.
</para>
</sect3>
@@ -1856,11 +1845,11 @@
</para>
<para>
- En el caso que deba mover o renombrar un archivo en el CVS,
- <emphasis>NO EJECUTE</emphasis> «cvs remove»
- y luego «cvs add». Si lo hace, los archivos
+ En el caso que debas mover o renombrar un archivo en el CVS,
+ <emphasis>NO EJECUTES</emphasis> «cvs remove»
+ y luego «cvs add». Si lo haces, los archivos
«nuevos» perderán la capacidad de seguir su
- historia de cambios, ya que desde el punto de vista de CVS
+ historial de cambios, ya que desde el punto de vista de CVS
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
@@ -1871,16 +1860,15 @@
<emphasis>Por favor</emphasis>, 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
- para mover los archivos por usted. Esto requiere
+ 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;
- <!-- FIXME -->
- if you move files in this
- erroneous way a CVS maintainer who has to go through this
- job will summon a flaming bat of death from hell to bite
- your head off. So please ask for someone to move the files
- for you.
+ 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
+ pregunta por una persona que pueda mover los archivos por
+ ti.
</para>
</sect3>
</sect2>
@@ -1896,7 +1884,7 @@
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, este puede cambiar de
+ 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.
</para>
@@ -1905,12 +1893,12 @@
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 es un mantenedor
- de paquetes, debiera aprender como usarlo. Autoconf y
- Automake tienen muchas áreas truculentas, así que siéntase
+ 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
libre de pedir ayuda en las listas de desarrollo de GNOME
- si tiene preguntas sobre la forma correcta de makefiles
- para su paquete.
+ si tienes preguntas sobre la forma correcta de construir
+ makefiles para tu paquete.
</para>
<para>
@@ -1932,10 +1920,10 @@
<!-- Memory Leaks Agenda -->
<sect1 id="memory-leak">
- <title>¿Por qué debería preocuparse por la pérdida de memoria?.</title>
+ <title>¿Por qué preocuparse por la pérdida de memoria?</title>
<para>
- Échele un vistazo a la lista de errores de Mozilla y una cosa es
+ É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.
@@ -1947,98 +1935,104 @@
<itemizedlist>
<listitem>
<para>
- Se comerá el área de intercambio lentamente. A la larga su
- programa, o hasta su máquina sucumbirán.
+ Se comerá el área de intercambio lentamente. A la larga tu
+ programa, o hasta tu máquina sucumbirán.
</para>
<para>
Nadie quiere que su programa o biblioteca adquiera la
- reputación de ser una porquería sólo porque uno ha sido
- vago. Déjeselo 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.
</para>
</listitem>
<listitem>
<para>
- Ocultan el mal uso de la memoria. Si olvida liberar la
- memoria, no hay forma de atrapar las lecturas y
- escrituras a esos trozos de memoria. Si posteriormente
- repara la pérdida, una parte completamente distinta
- del programa podría fallar.
- </para>
+ 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.
+ </para>
</listitem>
<listitem>
- <para>
- 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
- desea ver es que las todo iba como una seda antes de
- que empezara a toquetear y que, por lo tanto, le toca
- arreglar los problemas.
+ <para>
+ 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
+ el caos, y por lo tanto, esos problemas te corresponde a ti
+ arreglarlos.
</para>
<para>
Este es uno de los problemas de Mozilla actualmente:
- gotea sin parar así qiu ¿cómo va a saber si ha contribuido al problema?
+ pierde memoria sin parar así que ¿cómo vas a saber si has
+ contribuido al problema?
</para>
</listitem>
</itemizedlist>
</para>
<sect2 id="memory-advice">
- <title>Algunos consejos en la lucha contra la pérdida de memoria.</title>
+ <title>Algunos consejos contra la pérdida de memoria.</title>
<para>
<itemizedlist>
<listitem>
<para>
- Use «const» donde sea posible (para punteros obviamente).
- </para>
+ Usa «<symbol>const</symbol>» donde sea posible (para
+ punteros obviamente).
+ </para>
<para>
- Si un argumento es «const», entonces indudablemente la
- función llamada no liberará la memoria por usted.
- </para>
+ Si un argumento es «<symbol>const</symbol>», entonces
+ indudablemente la función llamada no liberará la memoria por
+ ti.
+ </para>
<para>
- Si el tipo de resultado de una función es «const», entonces
- claramente no es responsable por liberarlo.
- *Probablemente* lo será para un resultado distinto de
- «const» (que no sea un entero o algo similar).
- </para>
+ Si el tipo de resultado de una función es
+ «<symbol>const</symbol>», entonces
+ claramente no eres responsable por liberarlo.
+ <emphasis>Probablemente</emphasis> lo será para un resultado
+ distinto de «<symbol>const</symbol>» (que no sea un entero
+ o algo similar).
+ </para>
<para>
- Fíjese en que, desafortunadamente, esto no funciona muy bien
- con los objetos que cuentan referencias. Funciona bien
- con cadenas.
- </para>
+ Fíjate en que, desafortunadamente, esto no funciona muy bien
+ con los objetos que cuentan referencias. Funciona bien
+ con cadenas.
+ </para>
<para>
- Dado que C usa llamadas por valor, no tiene sentido
- aplicar «const» a tipos int, double y similares.
- </para>
+ Dado que C usa llamadas por valor, no tiene sentido
+ aplicar «<symbol>const</symbol>» a tipos
+ <symbol>int</symbol>, <symbol>double</symbol> y similares.
+ </para>
</listitem>
<listitem>
<para>
- <emphasis>Documente las responsabilidades.</emphasis>
+ <emphasis>Documenta las responsabilidades.</emphasis>
</para>
<itemizedlist>
<listitem>
<para>
- Si una función toma la propiedad de un objeto/referencia,
- sea explícito acerca de ello.
+ Si una función toma la propiedad de un objeto/referencia,
+ sé explícito acerca de ello.
</para>
</listitem>
<listitem>
<para>
- Indique siempre si el que llama a la función debiera
- liberar/desreferenciar los resultados.
+ Indica siempre si el que llama a la función debiera
+ liberar/desreferenciar los resultados.
</para>
</listitem>
<listitem>
<para>
- Documenta *cómo* entregar la memoria: unref, free,
- g_free, ...
+ Documenta <emphasis>cómo</emphasis> entregar la
+ memoria: unref, free, g_free, ...
</para>
</listitem>
</itemizedlist>
@@ -2046,72 +2040,75 @@
<listitem>
<para>
- <emphasis>Sea cuidadoso cuando use copiar-y-pegar.</emphasis>
+ <emphasis>Se cuidadoso cuando uses copiar-y-pegar.</emphasis>
</para>
<para>
El proceso de cortado y pegado no mejora el código, al
- contrario de lo que creen muchos programadores. Primero
- mire el código y si intenta producir muchas copias, quizás
- necesite una función de ayuda. <!-- FIXME: mejor
+ 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. <!-- FIXME: mejor
traducción de helper -->
</para>
</listitem>
<listitem>
<para>
- <emphasis>Libere todo antes de salir.</emphasis>
+ <emphasis>Libera todo antes de salir.</emphasis>
+ </para>
+ <para>
+ Esto lleva tiempo, así que quizás debieras hacerlo
+ sólo dentro de una condición.
+ </para>
+ <para>
+ 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.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis>No dejes punteros sueltos en tus estructuras de
+ datos.</emphasis>
+ </para>
+
+ <para>
+ Asigna <symbol>NULL</symbol> o
+ <symbol>(void *)0xdeadbeef</symbol> para los miembros
+ liberados a menos que vayas a liberar la estructura a la
+ que pertenecen.
+ </para>
+
+ <para>
+ Los punteros sueltos tienen la mala tendencia a ocultar pérdidas
+ de memoria.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis>Ejecuta el nuevo código en un ciclo 1 millón de
+ veces.</emphasis>
</para>
- <para>
- Esto lleva tiempo, así que quizás debiera hacerlo sólo dentro
- de una condición.
- </para>
+
<para>
- El motivo de este consejo es que los verificadores de memoria
- toman tiempo en determinar entre una pérdida que conoce y no
- le preocupa y las otras pérdidas.
+ Si pierdes memoria, lo sabrás — sólo sigue al proceso con
+ <command>top</command> en otra ventana. Podrías querer
+ especificar a top el <symbol>PID</symbol>
+ del proceso con la opción <parameter>-p</parameter>.
</para>
</listitem>
<listitem>
<para>
- <emphasis>No deje punteros sueltos en sus estructuras de
- datos.</emphasis>
+ <emphasis>Repáralo ahora, no después.</emphasis>
</para>
<para>
- Asigne NULL o (void *)0xdeadbeef para los miembros liberados a
- menos que vaya a liberar la estructura a la que pertenecen.
- </para>
-
- <para>
- Los punteros sueltos tienen la mala tendencia de ocultar pérdidas
- de memoria.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>Ejecute el nuevo código en un ciclo 1 millón de
- veces.</emphasis>
- </para>
-
- <para>
- Si pierde memoria, lo sabrá — sólo siga al proceso con
- top en otra ventana. Podría querer especificar a top el PID
- del proceso con la opción -p.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>Repárelo ahora, no después.</emphasis>
- </para>
-
- <para>
- No escriba una porquería de código; más temprano que tarde le
- pesará.
- </para>
+ No escribas una porquería de código; más temprano que
+ tarde te pesará.
+ </para>
</listitem>
</itemizedlist>
</para>