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
Última revisão Ambos lados da revisão seguinte
boas_praticas_de_programacao_shell_script [2018/08/17 15:22]
cartola /* Testes automatizados */
boas_praticas_de_programacao_shell_script [2019/09/25 09:41]
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
Linha 41: Linha 58:
 ======= Testes automatizados ======= ======= Testes automatizados =======
  
-Existem linguagens que tem ferramentas pra facilitar isso, mas trabalhando com o conceitoé possível fazer pra qualquer linguagem. Como Bash trabalha com funções, o melhor é refatorar o código de modo que funções recebam e retornem valores ou que executem coisas verificáveis, viabilizando testes externos que não necessariamente precisem executar as tarefas reais ou no ambiente real.+Existem linguagens que tem ferramentas pra facilitar isso, existe alias o [[https://github.com/bats-core/bats-core|BATS]] ([[https://hk.saowen.com/a/76a0859c6dbd6a2ac11c80dada4234fac367fdf43db39cf7e32992e46e8e1ed9|veja também esse guia]]) pro shell Bash, mas trabalhando com o conceito é possível fazer pra qualquer linguagem. Como Bash trabalha com funções, o melhor é refatorar o código de modo que funções recebam e retornem valores ou que executem coisas verificáveis, viabilizando testes externos que não necessariamente precisem executar as tarefas reais ou no ambiente real.
  
 Um script muitas vezes é pequeno e, nesses casos, a criação de testes talvez não se justifique. Se começar a crescer, se for complexo, se for ser alterado de tempos em tempos, então pode se considerar essa criação dos testes, que garantirá o funcionamento esperado de cada parte do código, evitando que uma eventual alteração faça com que se crie um bug. Essa é a moral da coisa. Um script muitas vezes é pequeno e, nesses casos, a criação de testes talvez não se justifique. Se começar a crescer, se for complexo, se for ser alterado de tempos em tempos, então pode se considerar essa criação dos testes, que garantirá o funcionamento esperado de cada parte do código, evitando que uma eventual alteração faça com que se crie um bug. Essa é a moral da coisa.
Linha 91: Linha 108:
 Exemplo: definindo múltiplas variáveis Exemplo: definindo múltiplas variáveis
   read filesystem total used free perc name < <(df . | tail -1)   read filesystem total used free perc name < <(df . | tail -1)
 +
 +
 +===== Lendo linha a linha e atribuindo colunas a variáveis =====
 +
 +  echo "Sistema"
 +  echo "  disponivel"
 +  df | grep -v "^Filesystem" | while read fs total used avail perc mount; do
 +    echo "$fs"
 +    echo "        $avail"
 +  done
 +Resultado da execução:
 +  $ ./exemplo.sh 
 +  Sistema
 +          disponivel
 +  /dev/mapper/system-root
 +          2014976
 +  devtmpfs
 +          8121660
 +  tmpfs
 +          8133648
 +
 +  *  opção de delimitador
 +  *  como jogar linha inteira numa variável
 +  *  readarray
  
boas_praticas_de_programacao_shell_script.txt · Última modificação: 2022/03/25 09:09 por cartola