Coding Patterns

#Organização do código

Como parte da política de gerenciamento de configuração do Redu é necessário seguir as seguintes recomendações durante o desenvolvimento.

##Trailing spaces

Antes de compartilhar qualquer código através do sistema de gerenciamento de versões é necessário remover todos espaços em branco ao fim das linhas. Tais espaços em branco geram uma série de problemas ao se realizar o diff entre dois arquivos, prejudicando o processo de merge. Para mais informações sobre este problema ver o artigo [1].

Muitos editores já possuem a funcionalidade de mostrar ou remover espaços em branco. Abaixo alguns exemplos:

###Vim

###GEdit

###TextMate

###Aptana

##Formatação

• Codificação UTF-8;
• Quebra de linha Unix-style;
• Deve-se utilizar uma linha em branco antes do retorno de um método, salvo a exceção de métodos que tenham apenas uma linha. Também deve-se utilizar entre definições de métodos.

def method
  a = 1
  b = a * 2

  "Hello"
end

def say_hello
  "Hello"
end

##Convenção de Nomes ###Métodos Deve-se utilizar apenas letras minúsculas e underlines: snake_case.

• ?: Utilizada no final do nome do método quando este retornar valores booleanos.
• !: Utilizada no final do nome do método quando este modifica o objeto self diretamente. Ao contrário do método sem ! que apenas deve retornar uma cópia modificada, sem modificar propriamente o self. Além disso, o método com ! deve levantar uma exceção em caso de erro, enquanto que o sem ! deve apenas retornar nil ou false em tais ocasiões.

###Classes e Módulos Deve-se utilizar CamelCase e manter os acrônimos como: HTTP, RFC, XML com letras maiúsculas.

###Constantes Deve-se utilizar SCREAMING_SNAKE_CASE.

##Identação do Código

Deve se utilizar dois espaços e não dois tabs.

###Blocos ERb Ruby Deve-se alinhar com o delimitador ERb %.

  <% if something %>
    something
  <% end %>

Casos em que o símbolo = aparece devem ser alinhados da seguinte maneira:

  <%= link_to 'Reenviar convite', resend_email_user_friendship_path(friendship_item.user, friendship_item),   
    :remote => true, :method => :post, :class => 'reinvite' %>

Observe que a linha de baixo continua alinhada com o símbolo %.

###Case Statements Deve-se alinhar os when e else no mesmo nível do case.

case thing
when 1
  do_one_thing
when 10
  do_ten_things
else
  do_nothing
end

Para casos em que os statments são simples, estes podem ficar na mesma linha do when.

case thing
when 1 then do_one_thing
when 2 then do_two_things
end

###Modificadores de Acesso Modificadores tais como public não definem blocos, portanto não deve haver identação após eles.

private

def a_private_method
  do_not_tell
end

###Quebra de linha Cada linha deve ter no máximo 80 colunas, salvo exceções que esta mofidicação traga pioras na legibilidade do código.

Exemplo de exceção:

@courses = Course.paginate(:conditions => ["public = 1 AND published = 1 AND state LIKE 'waiting'"],
                           :include => :owner,
                           :page => params[:page])                               

Após uma quebra de linha, a identação deve seguir o nível do parênteses do statment, como no exemplo acima.

##Comentários Devem ser utilizados apenas para facilitar o entendimento do código, nunca para comentar códigos antigos e deixá-los lá. Comentários de mais de uma palavra devem começar com letra maiúscula e utilizar pontuação.

##Snippets Javascript Estes devem estar apenas nas views, nunca misturados a código HTML (na forma <script type="text/javascript"></script>) ou nos controladores. Será considerado aceitável, caso seja realmente necessário a sua presença nos controladores.

##Active Record

###Ordenação do arquivo

1. Assinatura da classe
2. Requires e includes
3. Constantes
4. Callbacks
5. Relacionamentos
6. Named scopes
7. Accessors
8. Plugins
9. Validações

Opcionalmente pode-se dividir cada uma das seções com comentários.

###Métodos Os métodos devem ser escritos de acordo com a seguinte ordem:

1. Estáticos
2. Normais
3. Privados/Protected

##Views Evitar lógica nas views, elas devem ser simples. Para isso deve-se utilizar os helpers e os modelos (para filtragem, checagem, etc).

##No mais, use o bom senso.

#Referências

[1] http://stackoverflow.com/questions/1583406/why-does-git-care-about-trailing-whitespace-in-my-files

http://www.pathf.com/blogs/ruby-and-rails-style-guide/

http://github.com/chneukirchen/styleguide/blob/master/RUBY-STYLE

http://adzdavies.blogspot.com/2007/11/rails-coding-standard.html

Referência indicada pelo github: https://github.com/styleguide/ruby