ti_publica:desenvolvimento_de_sistemas:boas_praticas
Diferenças
Aqui você vê as diferenças entre duas revisões dessa página.
Próxima revisão | Revisão anteriorPróxima revisãoAmbos lados da revisão seguinte | ||
ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/04/02 17:42] – created cartola | ti_publica:desenvolvimento_de_sistemas:boas_praticas [2020/09/21 10:16] – [Dicas gerais] 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. | ||
- | =====Para escrever bom código===== | + | Veja também: |
+ | * [[: | ||
+ | * [[ti_publica: | ||
- | ====Geral==== | + | =====Dicas gerais===== |
- | * Use um lint(ou linter) pra checar vários aspectos do código. Ex: [https:// | + | * Use um [[https:// |
- | * Criar testes automatizados | + | * Crie testes automatizados |
- | * Não usar linhas maiores que 80 caracteres | + | * Não use linhas maiores que 80 caracteres |
- | * Crie e use bibliotecas de funções | + | * Crie e use funções, classes, |
+ | * Não faça blocos | ||
+ | * Primeira linha de um código interpretado (linha shebang): | ||
+ | * Em ambientes Unix like (Linux, BSDs, AIX, Solaris, Mac OS etc) | ||
+ | * prefira: # | ||
+ | * do que: # | ||
+ | * 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 | ||
- | ===Variáveis=== | + | ===IDE=== |
- | * Dar nomes descritivos a variáveis e funções | + | |
- | * Adotar camelCase ou snake_case para nomear variáveis e funções | + | |
- | * Adotar maiúsculas para constantes | + | |
- | * Não usar números diretamente, | + | |
- | * Evitar variáveis globais | + | |
- | * Para definir valores default pode usar a passagem de parâmetro pra função | + | |
- | + | ||
- | ===Funções / Objetos=== | + | |
- | * Descrever todas as funções | + | |
- | * Criar funções pequenas, segmentando o código | + | |
- | * Eliminar flags booleanos | + | |
- | * Ordem das funções de acordo com uso | + | |
- | * Nomes | + | |
- | * Nomes bem descritivos, | + | |
- | * Procurar usar sempre os mesmos verbos pras mesmas ações, não usar obter, pegar, get, ... escolher um. | + | |
- | * Evitar parâmetros desnecessários | + | |
- | * DRY (evitar ser repetitivo) | + | |
- | * Evitar efeitos colaterais | + | |
- | * Evitar variáveis globais!!!! (vale repetir) | + | |
- | + | ||
- | ===Testes automatizados=== | + | |
- | * 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__) | + | |
- | ===IDE=== | + | Eu uso o vim, mas essas funcionalidades provavelmente poderão ser encontradas em outras IDEs. |
- | * Use checagem | + | * Checagem |
- | * vim-syntastic | + | * [[https:// |
- | * vim-youcompleteme | + | * [[https:// |
+ | * Configurações no .vimrc: | ||
+ | * set textwidth=80 | ||
+ | * set wrapmargin=8 | ||
+ | * set columns=80 | ||
===Reuso=== | ===Reuso=== | ||
Linha 48: | Linha 39: | ||
* Ao criar número de versão no código use tipo string | * Ao criar número de versão no código use tipo string | ||
+ | ===Documentação=== | ||
- | ===ETC=== | + | 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:// |
+ | |||
+ | 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, | ||
+ | * Autor | ||
+ | * Histórico | ||
+ | * A fazer | ||
+ | * Comente os blocos: funções, classes, métodos, loops, variáveis ... | ||
+ | * Pylint pede doc para o arquivo, funções e classes, por exemplo | ||
+ | * vim-youcompleteme fornece as docs de funções ao digitar seus nomes | ||
**Exemplo de cabeçalho padrão (python):** | **Exemplo de cabeçalho padrão (python):** | ||
- | # | + | #!/usr/bin/env python3 |
# -*- coding: UTF-8 -*- | # -*- coding: UTF-8 -*- | ||
# | # | ||
Linha 59: | Linha 62: | ||
# | # | ||
# | # | ||
- | # Historico | + | # Historico |
# | # | ||
# | # | ||
Linha 67: | Linha 70: | ||
# - Tarefa 2 | # - Tarefa 2 | ||
# - subtarefa 2.1 | # - subtarefa 2.1 | ||
+ | |||
+ | ===Variáveis=== | ||
+ | * 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 e manter coerência num mesmo código | ||
+ | * Adotar maiúsculas para constantes | ||
+ | * Não usar números diretamente, | ||
+ | * Evitar variáveis globais | ||
+ | * Para definir valores default pode usar a passagem de parâmetro pra função | ||
+ | |||
+ | ===Funções / Objetos=== | ||
+ | * Descrever todas as funções nelas mesmas | ||
+ | * Criar funções pequenas, segmentando o código | ||
+ | * Eliminar flags booleanos | ||
+ | * Ordem das funções de acordo com uso | ||
+ | * Nomes | ||
+ | * Nomes bem descritivos, | ||
+ | * Procurar usar sempre os mesmos verbos pras mesmas ações, não usar obter, pegar, get, ... escolher um. | ||
+ | * Evitar parâmetros desnecessários | ||
+ | * DRY (evitar ser repetitivo) | ||
+ | * 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:// | ||
+ | |||
+ | ===Testes automatizados=== | ||
+ | * Algumas linguagens já tem frameworks prontos para adiantar esse trabalho, como o [[https:// | ||
+ | * Criar funções ou classes que recebam e retornem parâmetros testáveis, independentes das demais funções no mesmo código | ||
+ | * Criar outro programa que teste, com os testes programados ou preparar trecho do programa para atuar nos testes | ||
+ | * Não executar nada caso o programa seja carregado por outro. Isso em geral significa criar uma função ou área " | ||
+ | * Em Python pode se usar <code python> | ||
+ | * Em Shell pode se usar <code shell>if [ " | ||
+ | |||
+ | |||
+ | ===Senhas hardcoded=== | ||
+ | Em algumas situações seu programa precisa utilizar senhas. Se sua execução for agendada e 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? | ||
+ | * crie um arquivo de configuração | ||
+ | * coloque nele apenas permissão de leitura e apenas para o usuário necessário | ||
+ | * no programa original, opcionalmente, | ||
+ | * 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 | ||
+ | |||
+ | Na prática criei uma função numa biblioteca geral para carregar variáveis de configuração, | ||
+ | |||
+ | =====Internacionalização de código===== | ||
=====Referências===== | =====Referências===== | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
* Referência boa de livros de algumas linguagens populares: https:// | * Referência boa de livros de algumas linguagens populares: https:// | ||
* Vídeo [[https:// | * Vídeo [[https:// | ||
- | * [[https://en.wikipedia.org/wiki/Zen_of_Python|Zen of Python]] | + | |
+ | * [[https:// | ||
+ | | ||
+ |
ti_publica/desenvolvimento_de_sistemas/boas_praticas.txt · Última modificação: 2020/09/21 16:12 por cartola