# Contribuindo com o &arts;

## Como Eu Posso Ajudar

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 artsbuilder), músicos para criar modos de amostras para o &arts;, e escritores para escrever ou analisar a documentação.

## Listas de Discussão

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.

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 http://www.kde.org/mailinglists.html ou enviar uma mensagem eletrônica com o assunto `subscribe seu-endereço-eletrônico` para kde-multimedia-request@kde.org. A lista também é arquivada em http://lists.kde.org.

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 `subscribe seu-endereço-eletrônico` para arts-request@space.twc.de. A lista é arquivada em http://space.twc.de/~stefan/arts-archive.

## Padrões de Codificação

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.

Nomeando funções membro

  Estilo &Qt;/&Java;. Ou seja, capitalização nas quebras de palavra, e a primeira letra sempre sem capitalização, sem sublinhados.

  Isto significa, por exemplo:

      createStructureDesc()
         updateWidget();
         start();

Membros de classe

  Membros de classe não são capitalizados, assim como uma barra de menu ou botão.

  Onde estão acessando funções, o padrão deve ser o do &MCOP;, que é, ao ter um membro longo `foo`, que deve ser visível diretamente, você cria:

      foo(long new_value);
         long foo();

  funções para obter ou configurar o valor. Neste caso, o valor real de `foo` deve ser armazenado em _foo.

Nomes de classe

  Todas as classes devem ter capitalizadas as letras iniciais das palavras, o que significa ModuleView, SynthModule. Todas as classes que se originam de bibliotecas devem usar o espaço de nomes do &arts;, como Arts::Soundserver.

  A implementação de classes &MCOP; deve ser chamada Classe_impl, como SoundServer_impl.

Parâmetros

  Os parâmetros são sempre em minúsculas.

Variáveis locais

  Variáveis locais são sempre em minúsculas, e devem ter nomes como `i`, `p`, `x`, &etc; onde apropriado.

Largura da tabulação (largura do Shift)

  Uma tabulação deve ser tão longa quanto 4 espaços.

Espaços em expressões.

  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.

  Os exemplos a seguir demonstram o bom uso de espaços:

      {
          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);
      }

  Os exemplos a seguir demonstram como não usar espaços. Para chamadas de função, após if, while, for, switch e assim por diante, nenhum espaço deve ser escrito.

      {
          // 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 ();
      }

Nomes de arquivos fonte

  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 é `.cc` se eles referem-se a código independente para &Qt;/&GUI;, e `.cpp` se eles referem-se a código dependente do &Qt;/&GUI;. Arquivos de implementação para interfaces devem ser chamados `foo_impl`, se Foo foi o nome da interface.

  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.