Diferenças

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

--- ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/11/21 10:59] – [Geral] cartola
+++ ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/11/29 07:21] – cartola
@@ Linha 2: / Linha 2: @@
 Tentei reunir aqui boas práticas que gosto de usar para programar. São dicas pessoais que alguns podem preferir não usar, mas as obtive de várias fontes e muitas são de consenso
-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
+geral. Algumas são avaliadas para considerar se o código é bom. 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]]
+Veja também:
+  * [[:boas_praticas_de_programacao_shell_script|Boas práticas de programação shell]]
+  * [[ti_publica:dicas_python|Dicas para Python]]
-=====Para escrever bom código=====
+=====Dicas gerais=====
+  * Use um [[https://en.wikipedia.org/wiki/Lint_(software)|lint(ou linter)]] pra checar vários aspectos do código. Ex: [[https://www.pylint.org/|Pylint]] (python), [[https://www.shellcheck.net/|shellcheck]] (shell)
-====Geral====
-  * 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)
   * Crie testes automatizados
   * Não use linhas maiores que 80 caracteres
-  * Crie e use bibliotecas de funções: não faça blocos de código longos
+  * Crie e use funções, classes, bibliotecas
+  * Não faça blocos de código longos
+  * Primeira linha de um código interpretado (linha shebang):
+    * Em ambientes Unix like (Linux, BSDs, AIX, Solaris, Mac OS etc)
+      * prefira: #!/usr/bin/env python
+      * do que: #!/usr/bin/python
+      * fica mais flexível, mais chance de funcionar em ambientes distintos
+      * **não serve** caso precise de um interpretador específico que não o padrão do sistema
+  * Se for publicar seu código publique em inglês
 ===Documentação===
+Um projeto de software certamente necessita de arquivos somente de documentação com temas como escopo, regras de negócio, cronograma, papéis e responsabilidades da equipe, requisitos, licenças etc. Em projetos menores muitas vezes isso tudo pode estar num único arquivo LEIAME.txt ou, seguindo a tendência do [[https://help.github.com/pt/github/writing-on-github/basic-writing-and-formatting-syntax|github]], README.md, que pode ser escrito com [[https://pt.wikipedia.org/wiki/Markdown|Markdown]] e será apresentado ao acessar um diretório via web num repositório GIT.
+Isso tudo, porém, não exclui uma boa documentação no próprio código, que é do que falo aqui.
   * Use um cabeçalho em cada arquivo de código:
     * Descrição do propósito, parâmetros, requisitos, etc
@@ Linha 27: / Linha 40: @@
 **Exemplo de cabeçalho padrão (python):**
-  #!/usr/bin/python3
+  #!/usr/bin/env python3
   # -*- coding: UTF-8 -*-
   #