As boas práticas de programação

f46c46516f158e354bc8b526993df1bacc8d2bbe4ab0f595ae5f848cb9289320

Baseado em What are some bad programming practices every programmer needs to be aware of in order to avoid them?

As boas práticas de programação:

1) Comente seu código e suas funções, essas daí, comente antes mesmo de escrevê-las se possível: Deixar para comentar suas funções, algoritmos, etc., mais tarde, “quando estiver com tempo” não é uma boa ideia. Você provavelmente não o fará e se fizer não ficará tão bom. Comente antes de iniciar, ou, no máximo, assim que terminar. Além de você saber o que faz a função, você também se lembrará do motivo de estar fazendo aquilo.

2) Faça macros / códigos flexíveis: Evite ao máximo códigos estáticos. É pouco provável que suas variáveis serão sempre as mesmas. No começo pode parecer difícil, principalmente se você não está ainda familiarizado com a linguagem em questão. Como sempre, a prática leva a perfeição!

3) Valide os argumentos do seu método: Sempre que você faz um algoritmo qualquer que recebe uma variável inputada pelo usuário, você corre o risco da pessoa declarar algo que não é aceito pelo método. Por exemplo, se você criar uma função que recebe a variável data e com base nela você calcula a idade, você deve se certificar de que a variável data não é nula e está no formato de data. Nada que um if()não resolva. Um exemplo do que estou falando está no exercício 3 de R, em que você tem que fazer uma função que retorne o Valor Presente do investimento . Veja que verificamos se a data final é maior que a data inicial. Pode ser um bom exercício colocar uma verificação do formato da variável data inserida pelo usuário.

4) Faça boas escolhas para nomeações: Tente ser coerente e intuitivo com a sua nomenclatura ao longo de todo o código. Evite nomear variáveis com x e y, ao invés de nome e data, por exemplo. Eu procuro manter certos padrões como utilizar qtd para indicar quantidade, dt para data, cd para código, vlr para valor, fl para flag: qtd_parcelas, dt_nasc, cd_regiao, vlr_saldo, fl_

5) Idente seu código: Identar é o mesmo que alinhar o código, inserir espaços em determinados trechos, etc. Isso facilita muito, tanto para você quanto para outras pessoas que precisam compreender o que foi feito. Na hora de debugar você também terá seus ganhos. Para os usuários de sql, esse link deve ajudar: http://www.dpriver.com/pp/sqlformat.htm, para usuários do RStudio, selecionem o trecho do código e utilizem o atalho ctrl+i, o mesmo vale para quem usa SAS.

6) Não ignore cenários negativos: Pense bastante no “e se”. Tente visualizar diferentes cenários em que a execução vai retornar um erro. A variável está no formato certo? Há algum limitador para o número? As casas decimais podem afetar de alguma forma? E se houver linhas repetidas? E se houver nulos?

7) Não deixe que erros continuem no script silenciosamente sem investigá-los: Algumas mensagens do seu log podem ser meros avisos ou podem apontar uma falha que ocorre mesmo com o código sendo executado. Tenha certeza do que está ocorrendo.

8) Adote os padrões do código quando você começar a participar de um projeto já existente.

9) Utilize bibliotecas existentes: Se o software já possui suas próprias bibliotecas, com funções prontas, testadas e estressadas por diversas pessoas, é bem mais arriscado você criar o seu algoritmo do zero do que utilizar as bibliotecas.

10) Evite ao máximo correr contra o tempo: Essa você deveria levar ao seu chefe. Sabemos que programação serve inclusive para economizar tempo. Tarefas que duravam dias no passado, agora duram horas ou até mesmo minutos. Porém, essa economia na execução não pode fazer com que você tenha que fazer tudo para ontem. Escreva seu código com cuidado, debugue-o, tente otimizá-lo, execute alguns testes, estresse-o bastante para garantir que ele possa ser colocado em execução com segurança.

Por fim, sempre que possível, DOCUMENTE tudo que é feito. Com exceção dos bancos, em que a documentação faz parte da exigência do Bacen, na maioria dos lugares é difícil o gestor entender a importância de documentar seus códigos. Porém, não dá para fugir dessa tarefa. Documentação é importante para você e para seus colegas de trabalho que podem receber a tarefa de realizar alterações ou inclusões no seu código. Sem a documentação você com certeza vai ter dificuldades em recordar todas as variáveis, o motivo de alguns trechos do código, dentre outras coisas.

Anúncios

2 comentários

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s