Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- boas_praticas_de_programacao_shell_script [2019/08/02 18:16] – [Frameworks] cartola
+++ boas_praticas_de_programacao_shell_script [2022/03/25 12:09] (atual) – [Documentação] cartola
@@ Linha 17: / Linha 17: @@
   * [[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 =======
 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.
-**Código bem escrito**\\
+**Código bem escrito**
   *  **identação** - além de comentários, um código bem identado ajuda na compreensão da lógica. Shell não exige identação, o que pode ser uma armadilha - **DICA GERAL**
   *  **nomes de variáveis** - dê nomes de variáveis que indiquem seu significado e uso - **DICA GERAL**
   *  **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
   *  Nome do autor e data de criação
@@ Linha 37: / Linha 48: @@
   *  Resumo de parâmetros que recebe e que retorna
+**Interrompendo o programa em caso de erros**
+Alguns erros podem passar limpos pela execução de um shell e isso pode causar problemas difíceis de solucionar depois que o código cresce muito. Uma dica é colocar sempre no início do script a definição:\\
+''set -euo pipefail''
+(Fonte:[[https://pythonspeed.com/articles/shell-scripts/|Artigo externo]])
 ======= Estrutura do programa =======