Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/04/06 17:27] – [Referências] Incluindo cursos da USP no coursera cartola
+++ ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/07/31 11:25] – cartola
@@ Linha 4: / Linha 4: @@
 geral. Algumas dicas são genéricas, outras mais adequadas a uma ou outra linguagem. Quando comecei a escrever estava programando principalmente em python, mas também frequentemente em
 shell (principalmente bash) e as vezes em php. No passado já programei em C, pascal, perl, fortran e talvez alguma outra linguagem que não estou lembrando agora.
+Veja também [[:boas_praticas_de_programacao_shell_script|Boas práticas de programação shell]]
 =====Para escrever bom código=====
 ====Geral====
-  * Use um lint(ou linter) pra checar vários aspectos do código. Ex: [[https://www.pylint.org/]]
+  * Use um lint(ou linter) pra checar vários aspectos do código. Ex: [[https://www.pylint.org/|Pylint]] (python), [[https://www.shellcheck.net/|shellcheck]] (shell)
   * Criar testes automatizados
   * Não usar linhas maiores que 80 caracteres
@@ Linha 14: / Linha 16: @@
 ===Variáveis===
-  * Dar nomes descritivos a variáveis e funções
+  * Dar nomes descritivos a variáveis e funções, usar sempre mesmos verbos e substantivos
-  * Adotar camelCase ou snake_case para nomear variáveis e funções
+  * Adotar camelCase ou snake_case para nomear variáveis e funções e manter coerência num mesmo código
   * Adotar maiúsculas para constantes
   * Não usar números diretamente, crie uma constante que diga no nome o que ele é (ex: PI, RAIO_DA_TERRA, etc)
@@ Linha 22: / Linha 24: @@
 ===Funções / Objetos===
-  * Descrever todas as funções
+  * Descrever todas as funções nelas mesmas
   * Criar funções pequenas, segmentando o código
   * Eliminar flags booleanos
@@ Linha 33: / Linha 35: @@
   * Evitar efeitos colaterais
   * Evitar variáveis globais!!!! (vale repetir)
+===Formatação===
+Lembre-se que outra pessoa pode mexer no seu código mesmo que você não preveja isso inicialmente. Além disso você mesmo pode não lembrar mais o que você fez.
+  * Indente sempre bem ou pode entender errado que comandos estão dentro de que estruturas. Com uma IDE isso é bem fácil
+  * O uso de um lint(er) pode ajudar a identificar algumas faltas de padrão
+  * Um formatador, [[https://github.com/ambv/black|como o black pra Python]], ajuda a manter o código coerente (formatando coisas opcionais sempre da mesma forma) e legível
 ===Testes automatizados===
+  * Algumas linguagens já tem frameworks prontos para adiantar esse trabalho, como o [[https://docs.pytest.org/en/latest/|pytest para Python]], [[https://github.com/kward/shunit2|shUnit2]] ou [[https://liw.fi/cmdtest/|cmdtest/yarn]] para Shell, [[https://phpunit.de/|PHPUnit]] etc
   * Criar funções ou classes que recebam e retornem parâmetros testáveis
-  * Criar outro programa que teste, com os testes programados ou preparar trecho do programa para atuar nos testes (python pode usar o artifício do __main__)
+  * Criar outro programa que teste, com os testes programados ou preparar trecho do programa para atuar nos testes
+  * Uso de <code python>if __name__ == "__main__":</code> no Python para diferenciar quando o script está sendo chamado diretamente e quando está sendo carregado por outro, visando não executar o programa principal se estiver sendo testado
 ===IDE===
@@ Linha 43: / Linha 53: @@
     * vim-syntastic
     * vim-youcompleteme
+    * set textwidth=80
+    * set wrapmargin=8
+    * set columns=80
 ===Reuso===
@@ Linha 59: / Linha 72: @@
   #
   #
-  # Historico
+  # Historico (mais recente em cima)
   #       27.11.2018 - <identificação da pessoa> - Criação
   #       13.12.2018 - <identificação da pessoa> - Lorem Ipsilum