1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
<!-- <?xml version="1.0" ?>
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
To validate or process this file as a standalone document, uncomment
this prolog. Be sure to comment it out again when you are done -->
<chapter id="contributing">
<title>Contribuciones a &arts;</title>
<sect1 id="how-to-help">
<title>Cómo puede ayudar</title>
<para>El proyecto &arts; admite la ayuda de muchos desarrolladores para hacer que las aplicaciones multimedia existentes le soporten, para escribir nuevas aplicaciones multimedia, y para mejorar el propio &arts;. Sin embargo, no es necesario ser programador para colaborar. También se necesita ayuda de gente que haga pruebas de funcionamiento y envíe informes de fallos, traductores que adapten las aplicaciones y la documentación a otros idiomas, artistas que diseñen dibujos (especialmente para los módulos de <application>artsbuilder</application>), músicos que escriban módulos de ejemplo, y escritores que redacten la documentación. </para>
</sect1>
<sect1 id="mailing-lists">
<title>Listas de correo</title>
<para>La mayoría de las discusiones sobre el desarrollo de &arts; tienen lugar en dos listas de correo. Es el lugar para tratar nuevas características e ideas de implementaciones o para pedir ayuda ante los problemas. </para>
<para>La lista de correo Multimedia de &kde; trata temas generales de multimedia en &kde; así como aplicaciones multimedia como &noatun; y &aktion;. Puede suscribirse desde la página web <ulink url="http://www.kde.org/mailinglists.html"> http://www.kde.org/mailinglists.html</ulink> o enviar un correo electrónico con el asunto <userinput>subscribe <replaceable>su-dirección-de-correo</replaceable></userinput> a <email>kde-multimedia-request@kde.org</email>. La lista está guardada en <ulink url="http://lists.kde.org"> http://lists.kde.org</ulink>. </para>
<para>La lista de correo de &arts; trata temas específicos de &arts;, incluyendo el uso de &arts; externo a &kde;. Para suscribirse, envíe un correo electrónico que contenga en el cuerpo del mensaje <userinput>subscribe <replaceable>su-dirección-de-correo</replaceable></userinput> a <email>arts-request@space.twc.de</email>. La lista está guarda en <ulink url="http://space.twc.de/~stefan/arts-archive"> http://space.twc.de/~stefan/arts-archive</ulink>. </para>
</sect1>
<sect1 id="coding-standards">
<title>Estándares de programación</title>
<para>Para conseguir una lectura consistente de los códigos fuente, es importante mantener el mismo estilo de programación en todo el código de &arts;. Por favor, aunque escriba símplemente un módulo, trate de escribir y dar formato a su código fuente de acuerdo al estándar, así será más sencillo que otras personas mantegan esos archivos, y más fácil copiar porciones de un código a otro. </para>
<variablelist>
<varlistentry>
<term>Nombres de las funciones miembro</term>
<listitem>
<para>Estilo &Qt;/&Java;. Eso significa utilizar mayúsculas en los cambios de palabra, la primera letra en minúsculas y sin caracteres de subrayado. </para>
<para>Esto significa por ejemplo:</para>
<programlisting>crearDescripcionEstructura()
actualizarElemento();
iniciar(); </programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Miembros de clases</term>
<listitem>
<para>Los miembros de clases está en minúsculas, como 'barramenu' o 'boton'. </para>
<para>Cuando haya funciones de acceso, el estándar debe ser al estilo de &MCOP;, es decir, cuando haya un miembro largo <function>foo</function>, que no debe ser visible directamente, escriba funciones: </para>
<programlisting>foo(long nuevo_valor);
long foo(); </programlisting>
<para>para leer y establecer el valor. En ese caso, el valor real de <function>foo</function> debería quedar almacenado en <returnvalue>_foo</returnvalue>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Nombres de clases</term>
<listitem>
<para>Todas las clases deben comenzar con cada palabra en mayúsculas, como en <classname>ModuloVer</classname>, <classname>ModuloSintesis</classname>. Todas las clases que pertenezca a bibliotecas deben utilizar el espacio de nombres de &arts; como <classname>Arts::Servidorsonido</classname>. </para>
<para>Las implementaciones de las clases &MCOP; deben ser llamadas <classname>Clase_impl</classname>, como <classname>ServidorSonido_impl</classname>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Parámetros</term>
<listitem>
<para>Los parámetros van siempre en minúsculas. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Variables locales</term>
<listitem>
<para>La variables locales van siempre en minúsculas, y pueden tener nombres como <varname>i</varname>, <varname>p</varname>, <varname>x</varname>, &etc; según lo apropiado que sea. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Tabulación</term>
<listitem>
<para>Un tabulador tiene una longitud de 4 espacios. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Espacios en expresiones</term>
<listitem>
<para>Normalmente no es necesario utilizar espacios en expresiones. Puede, de todas formas, usarlos entre el operador y sus operandos. Sin embargo, si coloca un espacio antes de un operador (p.e. +), será necesario que coloque también uno después del mismo. La única excepción se produce en las expresiones de tipo de lista (con ,), donde sólo se debería poner un espacio después de la «,», pero nunca antes. Además, también es correcto omitir el espacio en este caso. </para>
<para>Los siguientes ejemplos muestran el uso correcto de los espacios: </para>
<programlisting>{
int a,b;
int c, d, e;
int f = 4;
a=b=c=d+e+f;
a = b = c = d + e + f;
if(a == 4) {
a = b = c = (d+e)/2;
}
while(b<3)
c--;
arts_debug("%d\n", c);
}
</programlisting>
<para>Los siguientes ejemplos muestras como <emphasis>no</emphasis> se deben utilizar los espacios. En las llamadas de función, después de if, while, for, swith y demás, no se debe escribir un espacio. </para>
<programlisting>{
// MAL: si escribe una lista, los espacios sólo deben ir después de la ","
int a , b , c , d , e , f;
// MAL: no se han utilizado los espacios simétricamente con el operador =
a= 5;
// MAL: if se considera una función y no debe ir seguida por un espacio
if (a == 5) {
}
// MAL: nunca escriba espacios después de while
while (a--)
b++;
// MAL: los nombres de funciones no deben ir seguidos por un espacio
arts_debug ("%d\n", c);
// MAL: tampoco los nombres de los miembros
Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Nombres de los archivos fuente</term>
<listitem>
<para>Los archivos fuente no deben tener mayúsculas en el nombre. Deben tener el nombre de la clase cuando implementen una sola clase. Su extensión es <literal role="extension">.cc</literal> si se refieren a código independiente de &Qt;/&GUI;, y <literal role="extension">.cpp</literal> si se refieren a código dependiente de &Qt;&GUI;. Los archivos de implementación para las interfaces deben llamarse <filename><replaceable>foo</replaceable>_impl</filename>, si Foo fuese el nombre del interfaz. </para>
<para>Los archivos &IDL; deben llamarse de una forma descriptiva de la colección de interfaces que contienen, también en minúsculas. No es bueno, concretamente, llamar al un archivo &IDL; como la propia clase, puesto que el intercambiador de mcopclass y las entradas de información de tipo colisionarán. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
</chapter>
|
