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ãoAmbos lados da revisão seguinte
boas_praticas_de_programacao_shell_script [2019/08/02 15:16] – [Frameworks] cartolaboas_praticas_de_programacao_shell_script [2019/09/25 08:28] – [Documentação] cartola
Linha 21: 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 30: 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
boas_praticas_de_programacao_shell_script.txt · Última modificação: 2022/03/25 09:09 por cartola