Ferramentas do usuário

Ferramentas do site


boas_praticas_de_programacao_shell_script

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
boas_praticas_de_programacao_shell_script [2018/08/17 16:54]
cartola /* Lendo arquivo linha a linha e atribuindo colunas a variáveis */
boas_praticas_de_programacao_shell_script [2019/09/25 09:41] (atual)
cartola [Frameworks]
Linha 1: Linha 1:
 +====== Programação Shell Script: boas práticas ======
 +Antes veja [[ti_publica:desenvolvimento_de_sistemas:boas_praticas|Desenvolvimento de sistemas: boas práticas]]
 +
 Esse é um guia pessoal de referência. Na maioria dos casos a dica se baseia no **Shell Bash**, mas muitas são genéricas. Anoto aqui dicas que considero úteis, de modo que possa acessá-las de qualquer lugar, aproveitando para compartilhar com quem possa ter interesse. Esse é um guia pessoal de referência. Na maioria dos casos a dica se baseia no **Shell Bash**, mas muitas são genéricas. Anoto aqui dicas que considero úteis, de modo que possa acessá-las de qualquer lugar, aproveitando para compartilhar com quem possa ter interesse.
  
Linha 5: Linha 8:
 Naturalmente algumas dicas aqui provavelmente servirão pra outras linguagens de programação. A medida que eu perceber isso vou tentar marcá-las como "**DICA GERAL**" Naturalmente algumas dicas aqui provavelmente servirão pra outras linguagens de programação. A medida que eu perceber isso vou tentar marcá-las como "**DICA GERAL**"
  
 +===== Referências Externas =====
 +
 +==== Gerais ====
 +  * [[http://kvz.io/blog/2013/11/21/bash-best-practices/|Bash best practices]]
 +==== Frameworks ====
 +  * [[https://invent.life/project/bash-infinity-framework/|Infinity framework]]
 +  * [[http://bashinator.org/|Bashinator]] - lista outros frameworks também
 +  * [[https://github.com/sstephenson/bats]] - Testes unitários automatizados
 +
 +==== IDE ====
 +
 +IDE é a sigla de Integrated Development Environment, que simplesmente se refere ao programa que se usa para escrever o código. Eu costumo escrever usando o [[https://www.vim.org/|Vim (Vi IMproved)]]. Sendo ele um editor genérico, é interessante configurá-lo pra facilitar a programação em shell.
  
 +  * Costumo identar com 2 espaços: set tabspace=2
 +  * Costumo limitar as linhas a 80 colunas:\\ set columns=80\\ set textwidth=80\\ set wrapmargin=8
 +  * Gosto do [[https://www.shellcheck.net/|Sellcheck]] que já verifica erros ao salvar o arquivo, dando dicas de melhores práticas.
 ======= Documentação ======= ======= Documentação =======
  
 Uma etapa bem sedimentada nos conceitos de engenharia de software é a documentação. Já vi muita documentação de sistemas e muito trabalho sendo contratado que exigia a criação de uma. Há uma documentação, porém, pra qual muitas vezes não é dada a devida atenção, seja em contratos comerciais, seja na verificação do produto final, mesmo que gerado internamente numa empresa ou por uma pequena equipe: comentários e código bem escrito. Uma etapa bem sedimentada nos conceitos de engenharia de software é a documentação. Já vi muita documentação de sistemas e muito trabalho sendo contratado que exigia a criação de uma. Há uma documentação, porém, pra qual muitas vezes não é dada a devida atenção, seja em contratos comerciais, seja na verificação do produto final, mesmo que gerado internamente numa empresa ou por uma pequena equipe: comentários e código bem escrito.
  
-**Comentários - **DICA GERAL** +**Comentários - DICA GERAL** 
-**\\   **regras de negócio** - um código bem comentado pode conter até as regras de negócio que estão normalmente num documento de especificação. Isso facilita a manutenção atualizada. No momento que a regra for alterada na prática, o programador está ali e pode ver que é necessário alterar o comentário.+  *  **regras de negócio** - um código bem comentado pode conter até as regras de negócio que estão normalmente num documento de especificação. Isso facilita a manutenção atualizada. No momento que a regra for alterada na prática, o programador está ali e pode ver que é necessário alterar o comentário.
   *  **lógica** - em outras situações o programador faz uma lógica mais complexa e não a explica em comentários. Isso é muito ruim, tanto para trabalho em equipe quanto para o próprio programador, quando tem que mexer nesse código meses depois.   *  **lógica** - em outras situações o programador faz uma lógica mais complexa e não a explica em comentários. Isso é muito ruim, tanto para trabalho em equipe quanto para o próprio programador, quando tem que mexer nesse código meses depois.
  
Linha 19: Linha 37:
   *  **nomes de variáveis minúsculos** - é um hábito de muitos programadores Shell o uso de nomes maiúsculos para variáveis. Isso aumenta o risco de acertar o nome de uma variável ambiente, essas sim, tradicionalmente maiúsculas.   *  **nomes de variáveis minúsculos** - é um hábito de muitos programadores Shell o uso de nomes maiúsculos para variáveis. Isso aumenta o risco de acertar o nome de uma variável ambiente, essas sim, tradicionalmente maiúsculas.
  
-**Cabeçalho - **DICA GERAL** +**Cabeçalho - DICA GERAL** \\ Use um cabeçalho padrão nos seus códigos. Um bom cabeçalho pode conter:
-**\\Use um cabeçalho padrão nos seus códigos. Um bom cabeçalho pode conter:+
   *  Descrição geral do que aquele código faz   *  Descrição geral do que aquele código faz
   *  Nome do autor e data de criação   *  Nome do autor e data de criação
boas_praticas_de_programacao_shell_script.1534535677.txt.gz · Última modificação: 2018/08/17 16:54 por cartola