Esta página tem por objetivo reunir as boas práticas para o desenvolvimento Android, para garantir uma melhor legibilidade do código. De maneira geral, um código legível é objetivo, simples e de fácil compreensão, não possui duplicidades, é eficiente e faz apenas o que é proposto. Para auxiliar na busca por este resultado, a seguir serão descritas boas práticas que visam a criação de um código fonte de qualidade. Ele é utilizado pela equipe de desenvolvimento, com o propositório de padronizar e manter uma melhor qualidade de código.
Grande parte deste material é baseado nos padrões da plataforma Android, descritos no Android Open Source Project Code Style
Todo o código deverá ser desenvolvido em português, salvo o uso de bibliotecas escritas em outro idioma e padrões de escrita de alguns arquivos descritos logo abixo. Esse padrão tem como objetivo facilitar o entendimento do código por todos, já que o português é a língua nativa dos integrantes do grupo.
O tamanho da indentação será o valor default configurado no Android Studio (4 espaços). Ainda em relação à indentação, é importante que todo o código alinhado esteja indentado, assim como as quebras de linhas longas. Em relação ao comprimento das linhas, fica definido o comprimento de demarcação do Android Studio (100 caracteres).
Criar nomes expressivos, que digam exatamente o que o elemento faz ou porque ele existe.
Os nomes de campos não públicos e não estáticos começam com m:
private int mPrivado;
Os nomes dos campos estáticos começam com s:
private static MinhaClasse sSingleton;
Os campos finais públicos estáticos (constantes) são escritos com todas as letras maiúsculas, com palavras separadas com underlines
public static final int SEGREDO_DA_VIDA_UNIVERSO_E_TUDO_MAIS = 42;
Outros campos começam com uma letra minúscula:
public int variavelPublica;
Toda classe e método público não trivial que você escreve deve conter um comentário Javadoc com pelo menos uma frase descrevendo o que a classe ou o método faz. Esta frase deve começar com um verbo descritivo de terceira pessoa.
/**
* Realiza o backup de uma base de dados local. Obtém os dados do dispositivo e
* faz a cópia em seu cartão de memória.
* @param context
* @throws IOException
*/
public static final void backupBancoDados(Context context) throws IOException {
File origem = new File("/data/data/" + context.getPackageName() + "/databases/", "backUP.db");
File destino = new File(Environment.getExternalStorageDirectory(), FILE);
org.apache.commons.io.FileUtils.copyFile(from, to);
}
Lembrando que o nome e o conteúdo de um método devem tornar o uso dos comentários desnecessário.
Sempre que possível, procure escrever métodos pequenos e focados. O método não deve fazer mais do que ele se propõe a fazer. Se um método exceder 40 linhas ou mais, pense se ele pode ser quebrado em outro(s) métodos sem prejudicar a estrutura do programa.
Declare as variáveis na parte superior do arquivo ou imediatamente antes do método que a utiliza.
As variáveis locais devem ser declaradas no ponto em que são usadas pela primeira vez. Todas as declarações de variável local devem conter um inicializador.
As variáveis de loop devem ser declaradas na declaração for, a menos que haja um bom motivo para fazer o contrário:
for (int i = 0; i < n; i++) {
facaAlgo(i);
}
for (Iterator i = c.iterator(); i.hasNext(); ) {
facaAlgo(i.next());
}
Procure sempre utilizar chaves para indicar blocos de código.
class MinhaClasse {
int funcao() {
if (algo) {
// faz algo...
} else {
// faz outra coisa...
}
}
}
Caso a estrutura condicional (condição e corpo) caibam em uma mesma linha, você pode (mas não é obrigado a faze-lo) colocar tudo em uma linha. Estes códigos serão aceitáveis:
if(condicao){
corpo();
}
if(condicao) corpo();
Mas esse tipo de código é uma má prática:
if(condicao)
corpo();
Quando as anotações são aplicadas a uma classe, método ou construtor, eles são listados após o bloco de documentação e devem aparecer como uma anotação por linha
/**Este é o bloco de documentação da classe */
@AnotacaoA
@AnotacaoB
public class MinhaClasse { }
As anotações que se aplicam as variáveis/atributos devem estar listadas na mesma linha e imediatamente antes da declaração da variável, a menos que a linha atinja o comprimento máximo.
@Nullable @Mock
DataManager dataManager;
O nome do pacote principal deve ser nomeado como o seguinte padrão:
com.<nome da empresa ou entidade>.<nome do projeto> e.g. br.com.exemplo.projetox
| Nome do Pacote | Descrição |
|---|---|
activities |
Contém todas as activities |
adapters |
Contém todas as classes para adapters customizados |
animations |
Contém todas as animações customizadas |
database |
Contém todas o material relacionado ao banco de dados |
dialogs |
Contém todas as dialogs ou dialog fragments customizados |
fragments |
Contém todas as classes do tipo fragments |
http |
Contém todas os adapters ou configurações de rede |
services |
Contém todas as interfaces não relacionadas a rede |
utils |
Contém todas as classes de auxilio e utilidades |
Nomes de Classes são escritas no padrão CamelCase
Para classes que estendem um componente Android, o nome da classe deve terminar com o nome do componente; por exemplo: SignInActivity, SignInFragment, ImageUploaderService, ChangePasswordDialog.
Os arquivos de layout devem corresponder ao nome dos componentes do Android para os quais eles se destinam, iniciando o nome com o tipo do componente.
Por exemplo se criarmos um layout para a classe EntrarActivity, o nome do arquivo de layout deve ser activity_entrar.xml.
| Componente | Nome da Classe | Nome do Arquivo de Layout |
|---|---|---|
| Activity | PerfilUsuarioActivity |
activity_perfil_usuario.xml |
| Fragment | EntrarFragment |
fragment_entrar.xml |
| Dialog | MudarSenhaDialog |
dialog_mudar_senha.xml |
| AdapterView item | --- | item_pessoa.xml |
| Content layout | --- | Content_status.xml |
Um caso ligeiramente diferente é quando criamos um layout que será inflado por um Adapter, por exemplo, para preencher um ListView. Nesse caso, o nome do layout deve começar com item_.
Veja que existem casos em que essas regras não serão possíveis de aplicar. Por exemplo, ao criar arquivos de layout que se destinam a fazer parte de outros layouts. Neste caso, você deve usar o prefixo content_.
Arquivos de recursos na pasta res\values são definidos no plural
por exemplo:
strings.xml - Strings Localizáveis
styles.xml - Contém todos os temas, Estilos de Layout
colors.xml - Lista de Cores
dimens.xml - Dimensões utilizadas nos layouts
config.xml - Guarda informações para configurar o projeto (urls, chaves de APIS)
Quando um elemento XML não tem nenhum conteúdo, você deve usar tags de auto-fechamento
Esta é uma boa prática:
<TextView
android:id="@+id/text_view_profile"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />Esta é uma má prática :
<!-- Não faça isso! -->
<TextView
android:id="@+id/text_view_profile"
android:layout_width="wrap_content"
android:layout_height="wrap_content" >
</TextView>Quando for criar identificadores nos arquivos de layout ou declarar variáveis do tipo de elementos de exibição, sempre tome o acrônimo do elemento como prefixo do identificador ou do nome da variável, por exemplo, TextView = tv.
| Elemento | Acrônimo | Exemplo |
|---|---|---|
TextView |
tv |
tvTexto |
ImageView |
iv |
ivImagem |
Button |
btn |
btnEnviar |
RadioButton |
rb |
rbSelecione |
EditText |
et |
etPalavras |
Spinner |
spinner |
spinnerSecione |
ListView |
lv |
lvLista |
Os nomes das strings começam com um prefixo que identifica a seção a que pertencem.
| Prefixo | Descrição |
|---|---|
app_ |
Uma mensagem ou texto geral do app |
error_ |
Uma mensagem de erro |
success_ |
Uma mensagem de sucesso |
caps_ |
Uma mensagem em CAPSLOCK |
required_ |
Indica um requisito para um campo |
info_ |
Uma mensagem de informação |
title_ |
Um título |
action_ |
Uma ação como "salvar" ou "Criar" |