Convenções de código Kotlin: Padrões para nomes

Teclado iluminado

Se você é um desenvolvedor Kotlin que procura aprender a escrever o seu código cada vez melhor, então você está no lugar certo! Pois veremos das convenções de código Kotlin essenciais, ou seja, os padrões para nomear arquivos, classes, funções e outras entidades existentes na linguagem.

Quer aprender mais sobre Kotlin tanto no mundo mobile como no back-end? Então confira este agregador de conteúdo onde listo todos os conteúdos que escrevi de Kotlin e os que serão publicados mais pra frente 😉

Seja também um desenvolvedor Kotlin

Preparado para descobrir se você está seguindo as convenções ou não? Ou melhor, preparado para deixar o seu código de acordo com as convenções oficiais do Kotlin? Então não perca tempo e confira!

Menina feliz na frente do computador

Pacotes

Tudo começa pela técnica inicial na qual organizamos os nossos arquivos, os famosos pacotes.

A princípio, seguimos o mesmo padrão do Java, tudo em minúsculo seguindo a ideia do domínio reverso (reverse domain), logo, se eu tiver o domínio alexf.com.br o meu pacote deve ser br.com.alexf, nenhum segredo por enquanto, certo?

Entretanto, podem existir casos que queremos deixar o nosso pacote com mais de uma palavra, como por exemplo, um pacote específico para uma API.

Vamos considerar a API do RecyclerView que possui diversas classes destinadas a ela, como um próprio Adapter, ViewHolder entre outras…

Se a nossa intenção é criar um pacote para ela, além de só deixar br.com.alexf.recyclerview, também somos capazes de manter o camel case considerando a primeira letra minúscula: br.com.alexf.recyclerView.

“Mas como ficam os arquivos fonte?”

Arquivos

Para arquivos fontes, temos as seguintes possibilidades:

• Extensão: eles sempre terão que manter .kt como sufixo;
• Tem apenas uma única classe: o nome precisa ser o mesmo dessa classe;
• Tem mais de uma classe: nesse caso, precisamos realizar uma análise, pois o nome do arquivo precisa descrever claramente o que todas as classes significam, como por exemplo, o arquivo Collections.kt. Repare que ele mantém diversas interfaces relacionadas às possíveis coleções do Kotlin, bem conveniente, concorda?

Lembre-se, a parte mais importante dessa abordagem é definir um nome para o arquivo que descreve muito bem o objetivo dele existir de acordo com o seu conteúdo.

"Legal, porém e o código?"

Nomeação no código

No geral, não temos muita novidade para quem vem do Java, pois seguimos exatamente o mesmo padrão para classes, interfaces, enums, funções (métodos do Java), properties e variáveis locais.

Em outras palavras, mantemos o famoso camel case, sendo que para classes (entenda que as interfaces e enums estão inclusos) a inicial é maiúscula e os demais membros mantendo a inicial minúscula.

Também temos uma peculiaridade do Kotlin, pois os Object Declarations mantém o mesmo padrão de classes. Além disso, há uma exceção para funções, ou seja, funções Factories também mantém o mesmo padrão de classe.

Casos peculiares de properties

Em um dos meus primeiros artigos de Kotlin, como também em meus cursos na Alura, eu afirmei que para declarar uma constante, bastava adicionar a keyword val e nomear seguindo o camel case com a primeira letra minúscula.

Entretanto, existem outros detalhes, como por exemplo, o const que, segundo a documentação, é uma técnica para definir constantes em tempo de compilação com algumas restrições, a que destaco, é que o valor deve ser um “primitivo” do Kotlin (Strings são consideradas também).

Nessa abordagem, seguimos o mesmo padrão adotado no Java, isto é, todas as letras maiúsculas separando cada palavra por underscore:

const val CODIGO_DE_BEBIDAS = 1

Esse padrão também é válido para properties val que não são locais (dentro de funções) e que recebem um primitivo:

val CODIGO_DE_BEBIDAS = 1

A única restrição para esse padrão, é que property val não pode ter o seu get() modificado. Mas é importante ressaltar que se a property for atribuída com um objeto, mantemos o padrão com a inicial em minúsculo.

A única exceção em constantes, seria para variáveis que representam um Object Declaration, ou seja, pode ainda manter o padrão camel case com a inicial em maiúsculo.

Aproveitando a abordagem das constantes, os membros de enums também mantém o mesmo padrão:

enum class Cores { 
    AZUL, AMARELO, VERMELHO
}

Bastante detalhe, né? Porém, perceba que a maioria dos padrões são bem próximos do que vemos no Java, se você já domina bem o Java, por enquanto não temos muitas novidades 😄

Entretanto, agora veremos algumas peculiaridades que pode ser impactante a primeira vista. Bora lá.

Properties de suporte

Properties de suporte, tecnicamente conhecidas como backing properties, é uma técnica na qual criamos uma property privada que pode ser manipulada apenas pelos membros da classe, e também, criamos uma ‘cópia’ pública dessa mesma property que é acessível por todos, principalmente para quem é de fora da classe.

"Muito abstrato, mostre-me o código!"

Um caso comum para essa abordagem, é o uso de listas mutáveis e imutáveis, isto é, criamos uma lista mutável que é acessível apenas pelos membros e uma imutável de suporte para quem é de fora:

class ProdutoDAO{

    private val _produtos: MutableList<Produto> = mutableListOf()
    
    val produtos: List<Produto> get() = _produtos

}

Veja que nessa amostra temos uma simulação de um DAO que mantém duas properties para uma lista de produto, a interna fica privada, mutável e com o prefixo _, enquanto a de suporte se mantém pública, imutável e tem o seu get() alterado para que devolva a interna que vai manter as informações necessárias.

Funções de teste

Um outro ponto que é bem peculiar (pelo menos pra mim) são as possibilidades para nomear apenas funções de testes.

Caso você não teve nenhum contato com testes, ou melhor, com o TDD, basicamente, os nomes de testes são frases que indicam o que será testado, por exemplo: “deve cadastrar um usuário”. Com esse exemplo, a função de teste fica da seguinte maneira:

@Test fun `deve cadastrar um usuario`() {
    // código do teste
}

Veja que é escapado com crase para possibilitar essa syntax que não é válida para o compilador por padrão. Entretanto, por enquanto, essa syntax não é suportada pelo Android, logo, o mesmo teste para Android ficaria assim:

@Test fun deveCadastrarUmUsuario_noAndroid(){
    // código de teste
}

Veja que nesse caso adicionamos um underscore para indicar que é um teste no Android.

Para saber mais

Além dessas regras que vimos, também existe outra técnica para escolher bons nomes para o código, como por exemplo, uma classe precisa ser um substantivo ou uma frase nominal que indica o que a classe é, como por exemplo: Produto, LeitorProduto.

Também existem outra regrinhas para outros membros de código, mas, nesse caso, vou deixar a referência para você consultar 😉

Coding Conventions - Kotlin Programming Language

Conclusão

Neste artigo vimos que para manter os nomes de pacotes, arquivos e código de acordo com o padrão esperado, é necessário seguir diversas regras que são bem comuns para os desenvolvedores Java.

Isso não significa que se escrever o código diferente das regras não vai funcionar, porém, manter o padrão acaba sendo benéfico quando trabalhamos em time ou quando compartilhamos o nosso projeto com outro desenvolvedor, pois a probabilidade para ele entender o seu código será bem maior 😃

O que achou dessas convenções do Kotlin? Deixe o seu ponto de vista nos comentários