Ferramentas do usuário

Ferramentas do site


ti_publica:desenvolvimento_de_sistemas:boas_praticas

Diferenças

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

Link para esta página de comparações

Ambos lados da revisão anterior Revisão anterior
Próxima revisão
Revisão anterior
ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/07/31 11:25]
cartola
ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/11/29 11:23] (atual)
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 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. 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) 
 +  * Crie testes automatizados 
 +  * Não use linhas maiores que 80 caracteres 
 +  * 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
  
-====Geral==== +===IDE==
-  * Use um lint(ou linterpra checar vários aspectos do código. Ex: [[https://www.pylint.org/|Pylint]] (python), [[https://www.shellcheck.net/|shellcheck]] (shell) + 
-  * Criar testes automatizados +Eu uso o vim, mas essas funcionalidades provavelmente poderão ser encontradas em outras IDEs. 
-  Não usar linhas maiores que 80 caracteres + 
-  * Crie use bibliotecas de funções+  * Checagem de sintaxe e auto complemento no VIM 
 +    * [[https://github.com/vim-syntastic/syntastic|vim-syntastic]] 
 +    * [[https://github.com/ycm-core/YouCompleteMe|vim-youcompleteme]] 
 +  * Configurações no .vimrc: 
 +    * set textwidth=80 
 +    * set wrapmargin=8 
 +    * set columns=80 
 + 
 +===Reuso=== 
 +  * Ao criar classes/códigos reusáveis, defina a versão (no nível da classe, não da instância) 
 +  * Ao criar número de versão no código use tipo string 
 + 
 +===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 etcEm 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 
 +    * Autor 
 +    * Histórico 
 +    * A fazer 
 +  * Comente os blocos: funções, classes, métodos, loops, variáveis ... 
 +    * Pylint pede doc para o arquivo, funções classes, por exemplo 
 +    * vim-youcompleteme fornece as docs de funções ao digitar seus nomes 
 + 
 +**Exemplo de cabeçalho padrão (python):** 
 + 
 +  #!/usr/bin/env python3 
 +  # -*- coding: UTF-8 -*- 
 +  # 
 +  # <Descrição> A segunda linha acima permite o uso de acentuação no arquivo 
 +  # 
 +  # 
 +  # Historico (mais recente em cima) 
 +  #       27.11.2018 - <identificação da pessoa> - Criação 
 +  #       13.12.2018 - <identificação da pessoa> - Lorem Ipsilum 
 +  # 
 +  # A Fazer 
 +  #       - Tarefa 1 
 +  #       - Tarefa 2 
 +  #               - subtarefa 2.1
  
 ===Variáveis=== ===Variáveis===
Linha 48: Linha 104:
   * 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   * 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=== 
  
-  * Use checagem de sintaxe no VIM auto compleção +===Senhas hardcoded=== 
-    vim-syntastic +Em algumas situações seu programa precisa utilizar senhas. Se sua execução for agendada não houver uma pessoa para passar a senha na hora, como fazer? Colocar a senha hardcoded? E se seu código estiver sendo guardado num sistema de controle de versão, o que é uma boa prática? 
-    vim-youcompleteme +  crie um arquivo de configuração 
-    set textwidth=80 +  coloque nele apenas permissão de leitura e apenas para o usuário necessário 
-    set wrapmargin=8 +  no programa original, opcionalmente, verifique o proprietário e permissão necessária do arquivo de configuração, abortando para garantir acerto se alguém alterar acidentalmente 
-    * set columns=80+  não coloque o arquivo de configuração no sistema de controle de versão ou coloque-o com um pré-nome, tipo config-sample
  
-===Reuso=== +Na prática criei uma função numa biblioteca geral para carregar variáveis de configuraçãopor conta disso meu arquivo de configuração é homônimo ao programa original adicionado de uma extensão padrão.
-  * Ao criar classes/códigos reusáveisdefina a versão (no nível da classe, não da instância) +
-  * Ao criar número de versão no código use tipo string+
  
- +=====Internacionalização de código=====
-===ETC==+
- +
-**Exemplo de cabeçalho padrão (python):** +
- +
-  #!/usr/bin/python3 +
-  # -*- coding: UTF-8 -*- +
-  # +
-  # <Descrição> A segunda linha acima permite o uso de acentuação no arquivo +
-  # +
-  # +
-  # Historico (mais recente em cima) +
-  #       27.11.2018 - <identificação da pessoa> - Criação +
-  #       13.12.2018 - <identificação da pessoa> - Lorem Ipsilum +
-  # +
-  # A Fazer +
-  #       - Tarefa 1 +
-  #       - Tarefa 2 +
-  #               - subtarefa 2.1+
  
 =====Referências===== =====Referências=====
Linha 88: Linha 123:
     *  [[https://www.coursera.org/learn/ciencia-computacao-python-conceitos|Introdução à Ciência da Computação com Python Parte 1]]     *  [[https://www.coursera.org/learn/ciencia-computacao-python-conceitos|Introdução à Ciência da Computação com Python Parte 1]]
     * [[https://www.coursera.org/learn/ciencia-computacao-python-conceitos-2|Introdução à Ciência da Computação com Python Parte 2]]     * [[https://www.coursera.org/learn/ciencia-computacao-python-conceitos-2|Introdução à Ciência da Computação com Python Parte 2]]
 +
 +
ti_publica/desenvolvimento_de_sistemas/boas_praticas.1564583149.txt.gz · Última modificação: 2019/07/31 11:25 por cartola