As funções anotadas com @Composable que retornam Unit são PascalCased e nomeadas como substantivos, como se fossem tipos.
Nomes de constante usam UPPER_SNAKE_CASE: todas as letras maiúsculas, com palavras separadas por sublinhados. Mas o que é uma constante, exatamente?
Constantes são propriedades val sem nenhuma função get personalizada, cujos conteúdos são imutáveis e cujas funções não têm efeitos colaterais detectáveis. Isso inclui tipos imutáveis e coleções imutáveis de tipos imutáveis, bem como escalares e strings, se marcados como const. Se algum estado observável da instância puder ser modificado, ele não será uma constante. Apenas tentar não mudar o objeto não é suficiente.
Os valores constantes só podem ser definidos dentro de object ou como uma declaração de nível superior. Valores que atendam ao requisito de uma constante, mas são definidos dentro de um class precisam usar um nome não constante.
Nomes não constantes são escritos em camelCase. Eles se aplicam a propriedades de instâncias, propriedades locais e nomes de parâmetros.
Quando uma propriedade de backup é necessária, o nome tem que corresponder exatamente ao da propriedade real, exceto o prefixo com um sublinhado.
Às vezes, há mais de uma maneira razoável de converter uma frase em inglês em letras concatenadas, como quando acrônimos ou construções incomuns como "IPv6" ou "iOS" estão presentes. Para melhorar a previsibilidade, use o seguinte esquema.
Divida esse resultado em palavras, dividindo em espaços e qualquer pontuação restante (normalmente hifens). Recomendado: se alguma palavra já tiver uma aparência de concatenação convencional de uso comum, divida-a nas partes constituintes (por exemplo, "AdWords" se torna "ad words"). Uma palavra como "iOS" não é realmente concatenada; ela desafia qualquer convenção, então essa recomendação não se aplica.
Coloque em maiúscula o primeiro caractere de cada palavra, exceto a primeira, para produzir a concatenação.
Observação: algumas palavras têm hifenização ambígua no idioma inglês. Por exemplo, "nonempty" e "non-empty" estão corretos, de modo que os nomes dos métodos checkNonempty e checkNonEmpty também estão corretos.
A forma básica é sempre aceitável. A forma de uma única linha pode ser substituída quando a totalidade do bloco KDoc (incluindo marcadores de comentário) couber em uma única linha. Isso só se aplica quando não há tags de bloco, como @return.
Uma linha em branco, ou seja, uma linha contendo apenas o asterisco inicial alinhado (*), aparece entre os parágrafos e antes do grupo de tags de bloco, se houver.
Qualquer uma das "tags de bloco" padrão que são usadas aparece na ordem @constructor, @receiver, @param, @property, @return, @throws, @see e elas nunca aparecem com uma descrição vazia. Quando uma tag de bloco não se encaixa em uma única linha, as linhas de continuação são recuadas 4 espaços a partir da posição de @.
Cada bloco KDoc começa com um breve fragmento de resumo. Esse fragmento é muito importante: é a única parte do texto que aparece em determinados contextos, como índices de classe e método.
Isso é um fragmento: uma frase nominal ou uma frase verbal, não uma frase completa. Não começa com "A `Foo` is a..." ou "This method returns...", nem tem que formar uma frase imperativa completa como "Save the record.". No entanto, o fragmento é capitalizado e pontuado como se fosse uma frase completa.
No mínimo, o KDoc está presente para cada tipo public e todo membro public ou protected desse tipo, com algumas exceções indicadas abaixo.