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>Contribuindo com o &arts;</title>
<sect1 id="how-to-help">
<title>Como Eu Posso Ajudar</title>
<para>O projeto &arts; pode se beneficiar da ajuda de desenvolvedores para tornar os aplicativos multimídia existentes compatíveis com o &arts;, escrever novos aplicativos multimídia, e incrementar os recursos do &arts;. No entanto, você não precisa ser um desenvolvedor para contribuir. Nós podems também nos beneficiar de testadores para submeter relatórios de erros, tradutores para traduzir o texto e documentação do aplicativo para outros idiomas, artistas para desenhar bitmaps (especialmente para os módulos do <application>artsbuilder</application>), músicos para criar modos de amostras para o &arts;, e escritores para escrever ou analisar a documentação. </para>
</sect1>
<sect1 id="mailing-lists">
<title>Listas de Discussão</title>
<para>A maioria das discossões sobre o desenvolvimento do &arts; ocorrem em duas listas. Elas são o local para discutir novos recursos e idéias de implementação ou pedir ajuda quando problemas acontecem. </para>
<para>A lista de discussão de Multimídia do &kde; é para questões gerais sobre multimídia no &kde; incluindo o &arts; bem como aplicativos multimídia como o &noatun; e &aktion;. Você pode inscrever-se a partir da página web em <ulink url="http://www.kde.org/mailinglists.html">http://www.kde.org/mailinglists.html</ulink> ou enviar uma mensagem eletrônica com o assunto <userinput>subscribe <replaceable>seu-endereço-eletrônico</replaceable></userinput> para <email>[email protected]</email>. A lista também é arquivada em <ulink url="http://lists.kde.org">http://lists.kde.org</ulink>. </para>
<para>A lista de discussão do &arts; é para questões específicas do &arts;, incluindo uso não-&kde; do &arts;. Para inscrever-se, envie uma mensagem eletrônica contendo o corpo da mensagem <userinput>subscribe <replaceable>seu-endereço-eletrônico</replaceable></userinput> para <email>[email protected]</email>. A lista é arquivada em <ulink url="http://space.twc.de/~stefan/arts-archive">http://space.twc.de/~stefan/arts-archive</ulink>. </para>
</sect1>
<sect1 id="coding-standards">
<title>Padrões de Codificação</title>
<para>Para obter uma leitura consistente em todas as fontes, é importante manter o mesmo estilo de código, em todos arquivos de código fonte do &arts;. Por favor, se você acabou de escrever um módulo, tente escrever/formatar seu código de acordo, assim ficará mais fácil para as diferentes pessoas manter a árvore de código fonte, e mais fácil copiar partes de código de um arquivo para outro. </para>
<variablelist>
<varlistentry>
<term>Nomeando funções membro</term>
<listitem>
<para>Estilo &Qt;/&Java;. Ou seja, capitalização nas quebras de palavra, e a primeira letra sempre sem capitalização, sem sublinhados. </para>
<para>Isto significa, por exemplo:</para>
<programlisting>createStructureDesc()
updateWidget();
start(); </programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Membros de classe</term>
<listitem>
<para>Membros de classe não são capitalizados, assim como uma barra de menu ou botão. </para>
<para>Onde estão acessando funções, o padrão deve ser o do &MCOP;, que é, ao ter um membro longo <function>foo</function>, que deve ser visível diretamente, você cria: </para>
<programlisting>foo(long new_value);
long foo(); </programlisting>
<para>funções para obter ou configurar o valor. Neste caso, o valor real de <function>foo</function> deve ser armazenado em <returnvalue>_foo</returnvalue>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Nomes de classe</term>
<listitem>
<para>Todas as classes devem ter capitalizadas as letras iniciais das palavras, o que significa <classname>ModuleView</classname>, <classname>SynthModule</classname>. Todas as classes que se originam de bibliotecas devem usar o espaço de nomes do &arts;, como <classname>Arts::Soundserver</classname>. </para>
<para>A implementação de classes &MCOP; deve ser chamada <classname>Classe_impl</classname>, como <classname>SoundServer_impl</classname>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Parâmetros</term>
<listitem>
<para>Os parâmetros são sempre em minúsculas. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Variáveis locais</term>
<listitem>
<para>Variáveis locais são sempre em minúsculas, e devem ter nomes como <varname>i</varname>, <varname>p</varname>, <varname>x</varname>, &etc; onde apropriado. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Largura da tabulação (largura do Shift)</term>
<listitem>
<para>Uma tabulação deve ser tão longa quanto 4 espaços. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>Espaços em expressões.</term>
<listitem>
<para>Você normalmente não precisa usar espaços em expressões. Você pode entretanto usá-los entre o operador e seus operandos. No entanto, se você colocar um espaço antes de um operador (por exemplo o +), você também deve colocar um espaço após o operador. A única exceção a isto são expressões estilo lista (com ,), onde você deve colocar um espaço após a "," mas não antes. Não há problemas se omitir o espaço aqui também. </para>
<para>Os exemplos a seguir demonstram o bom uso de espaços: </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>Os exemplos a seguir demonstram como <emphasis>não</emphasis> usar espaços. Para chamadas de função, após if, while, for, switch e assim por diante, nenhum espaço deve ser escrito. </para>
<programlisting>{
// RUIM: se você escreveu uma lista, espaços em branco somente após a ","
int a , b , c , d , e , f;
// RUIM: uso não simétrico de espaços para o operador =
a= 5;
// RUIM: se é considerada uma função, e não é seguida por um espaço
if (a == 5) {
}
// RUIM: não escreva um espaço após while
while (a--)
b++;
// RUIM: nomes de funções não são seguidos por um espaço
arts_debug ("%d\n", c);
// RUIM: não são nomes de membro
Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>Nomes de arquivos fonte</term>
<listitem>
<para>Arquivos fonte não devem ter capitalização no nome. Eles devem ter o nome da classe quando implementam uma classe única. Sua extensão é <literal role="extension">.cc</literal> se eles referem-se a código independente para &Qt;/&GUI;, e <literal role="extension">.cpp</literal> se eles referem-se a código dependente do &Qt;/&GUI;. Arquivos de implementação para interfaces devem ser chamados <filename><replaceable>foo</replaceable>_impl</filename>, se Foo foi o nome da interface. </para>
<para>Arquivos &IDL; devem ser chamados de uma maneira descritiva para a coleção de interfaces que eles contém, também tudo em minúsculas. Especialmente não é uma boa idéia chamar um arquivo &IDL; como a classe propriamente dita, assim como o negociador mcopclass e inserir entradas de informação conflitantes. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
</chapter>
|
