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 anteriorRevisão anterior
Próxima revisão
Revisão anterior
Próxima revisãoAmbos lados da revisão seguinte
boas_praticas_de_programacao_shell_script [2018/08/17 15:37] – /* Testes automatizados */ cartolaboas_praticas_de_programacao_shell_script [2019/09/25 08:28] – [Documentação] cartola
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
  
 ======= Documentação ======= ======= Documentação =======
Linha 10: Linha 21:
 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 30:
   *  **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 91: Linha 101:
 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