ti_publica:desenvolvimento_de_sistemas:boas_praticas
Diferenças
Aqui você vê as diferenças entre duas revisões dessa página.
| Ambos lados da revisão anteriorRevisão anteriorPróxima revisão | Revisão anteriorPróxima revisãoAmbos lados da revisão seguinte | ||
| ti_publica:desenvolvimento_de_sistemas:boas_praticas [2019/04/08 10:41] – [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 | 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 | ||
| + | |||
| + | ===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:// | ||
| + | |||
| + | 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: | ||
| + | * 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): | ||
| + | |||
| + | # | ||
| + | # -*- coding: UTF-8 -*- | ||
| + | # | ||
| + | # < | ||
| + | # | ||
| + | # | ||
| + | # Historico (mais recente em cima) | ||
| + | # | ||
| + | # | ||
| + | # | ||
| + | # A Fazer | ||
| + | # - Tarefa 1 | ||
| + | # - Tarefa 2 | ||
| + | # - subtarefa 2.1 | ||
| ===Variáveis=== | ===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 |
| * Adotar maiúsculas para constantes | * Adotar maiúsculas para constantes | ||
| * Não usar números diretamente, | * Não usar números diretamente, | ||
| Linha 22: | Linha 64: | ||
| ===Funções / Objetos=== | ===Funções / Objetos=== | ||
| - | * Descrever todas as funções | + | * Descrever todas as funções |
| * Criar funções pequenas, segmentando o código | * Criar funções pequenas, segmentando o código | ||
| * Eliminar flags booleanos | * Eliminar flags booleanos | ||
| Linha 48: | Linha 90: | ||
| ===IDE=== | ===IDE=== | ||
| - | | + | Eu uso o vim, mas essas funcionalidades provavelmente poderão ser encontradas em outras IDEs. |
| - | * vim-syntastic | + | |
| - | * vim-youcompleteme | + | |
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * Configurações no .vimrc: | ||
| + | * set textwidth=80 | ||
| + | * set wrapmargin=8 | ||
| + | * set columns=80 | ||
| ===Reuso=== | ===Reuso=== | ||
| * Ao criar classes/ | * Ao criar classes/ | ||
| * 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 | ||
| - | |||
| - | |||
| - | ===ETC=== | ||
| - | |||
| - | **Exemplo de cabeçalho padrão (python):** | ||
| - | |||
| - | # | ||
| - | # -*- coding: UTF-8 -*- | ||
| - | # | ||
| - | # < | ||
| - | # | ||
| - | # | ||
| - | # Historico | ||
| - | # | ||
| - | # | ||
| - | # | ||
| - | # A Fazer | ||
| - | # - Tarefa 1 | ||
| - | # - Tarefa 2 | ||
| - | # - subtarefa 2.1 | ||
| =====Referências===== | =====Referências===== | ||
ti_publica/desenvolvimento_de_sistemas/boas_praticas.txt · Última modificação: 2020/09/21 16:12 por cartola