Implantar um coding style

[gmgall]

Não há um padrão de estilo de código hoje. Pelo menos código novo deve estar em conformidade com algum coding style. Idealmente, o projeto todo.

Uma sugestão de estilo é dada pelo Hadley Wickham no Advanced R. O coding style dele é quase igual ao do Google, com algumas poucas modificações.

Acho ambos bons, faria uma ressalva apenas a usar só 2 espaços para indentação. A PEP-8 do Python sugere 4 espaços. Abri essa issue para discutirmos esses detalhes. Manter consistência é o mais importante, independente da nossa decisão.

Um pacote R que pode nos ajudar na empreitada de implantar um estilo é o formatR.

[AndreaSanchezTapia]

Oi Guilherme, acho super pertinente esta discussão. Em geral o nosso estilo tem melhorado... mas ainda falta polir várias partes. Concordo com seguir as guidelines do Wickham. Vou fazer.

Você quer testar o pacote? Eu achava que o RStudio vinha com ele porque tem uma opção de formatar o código. Quando ele faz, ele insire linhas novas entre as vírgulas das chamadas das funções, não apenas na definição delas, aí fica muito chato. Mas o resto eu acho tranquilo.
Mas vi aqui que não é o pacote, mas que dá para usar o formatR como addin do RStudio - a pessoa concorda comigo que essas novas linhas são "overkill" XD.
A gente fecha esta issue quando tudo estiver bem formatado ou mantém como recordatório?

[AndreaSanchezTapia]

uma coisa que não é muito dita é sobre a identação e aí vc vai ter que nos guiar.

• se eu abrir uma parêntese o melhor é que a linha seguinte comece ao nível da parêntese
• se eu definir uma função os parâmetros devem estar alinhados
• e o resto das vezes? 🙈

[gmgall]

Você quer testar o pacote?

Testarei. Aviso o que achei aqui depois.

A gente fecha esta issue quando tudo estiver bem formatado ou mantém como recordatório?

Eu manteria aberta até estarmos satisfeitos com o estilo usado no projeto todo. Cada commit que muda só o estilo pode referenciar esse issue e ele vai aparecer aqui. Acho uma boa forma de coordenar o esforço.

Mas isso a gente tem que decidir como uma equipe. Se vocês acharem melhor fechar, fechamos. Eu não tenho nada contra issues de longa duração. Como falei, vejo o recurso como uma forma de coordenar esforços. Eles podem ser resolvidas em curto prazo ou não.

Qual a opinião de vocês? (alô @FelipeSBarros)

uma coisa que não é muito dita é sobre a identação e aí vc vai ter que nos guiar.

se eu abrir uma parêntese o melhor é que a linha seguinte comece ao nível da parêntese
se eu definir uma função os parâmetros devem estar alinhados
e o resto das vezes?

Pode dar um exemplo de "resto das vezes" que possa causar confusão? Porque realmente os guias que citei como exemplo são lacônicos ao falarem de parênteses. O do Google fala apenas:

Indentation
          
            When indenting your code, use two spaces.  Never use tabs or mix
            tabs and spaces.
            
              Exception: When a line break occurs inside parentheses,
              align the wrapped line with the first character inside the
              parenthesis.

Se aparecer uma situação que os guias do Wickham/Google não cubram, temos vários outras orientações para seguir, especialmente quando o assunto é indentação.

Como esperado, as pessoas ainda brigam para defender o seu padrão preferido. 😅

[FelipeSBarros]

Opa, não tenho estilo preferido. Aliás, estou aprendendo na marra a importância da identação (ao aprender Python).
Lembro de já termos iniciado essa discussão antes, mas informalmente. E ao que me lembro, chegamos no mesmo ponto: a formatação automática do RStudio é exagerada ao incluir muitas linhas em branco.
Acho melhor irmos conforme orientação do Wickham, mas sem nos prendermos a isso. Lembrando que o que queremos é padronizar e facilitar a leitura do código. Correto?

[gmgall]

Lembrando que o que queremos é padronizar e facilitar a leitura do código. Correto?

Correto, mas não só. Também é importante para não nos atrapalharmos ao colaborarmos. Se eu uso espaços e outros colaboradores usam tabs, um git diff vai mostrar diferenças, mesmo que a linha pareça "igual".

[AndreaSanchezTapia]

vamos manter o do wickham então, usando ou não o pacote -como cada um preferir.
nåø fechemos a issue :)

[gmgall]

Fiz push de um branch chamado iss1 para vocês verem os efeitos do formatR.

Ele tem 3 commits, para vocês poderem ver as alterações sucessivas no código:

• f436c7a remove os comentários inline. A versão do formatR no CRAN não se deu bem com isso. Foi uma modificação manual, só para fazer o formatR rodar sem erros.
• f954bfe reformata todos os scripts em ENM/fct/ com 80 colunas e indentação = 4 espaços (PEP-8 e default do formatR)
• c1a56a9 reformata todos os scripts em ENM/fct/ com 80 colunas e indentação = 2 espaços (Wickham/Google)

Se gostarem, faço o merge. Se não gostarem, ignorem o branch iss1.