Um problema comum em quase todas as profissões que podem levar as pessoas completamente a loucura é ter de continuar o trabalho a partir do que alguém começou. A principal razão para isso é o fato de que cada um tem formas diferentes de trabalhar, e às vezes isso pode causar uma bela confusão.

A fim de tornar o código mais limpo e apoiar o trabalho em equipe (o que significa que alguém pode precisar trabalhar com o que foi codificado antes), existem algumas considerações (e dicas) que devem ser levadas em conta.

01. Revise sua lógica antes da codificação

Antes de escolher a sua IDE favorita (que com certeza é o Eclipse), alguns diagramas de fluxo ou um pseudo-código podem ser úteis para verificar previamente a lógica do seu futuro código. Fazer isso primeiro pode esclarecer muitas dúvidas e inseguranças sobre a funcionalidade do seu complexo código, economizando muito tempo.

O mais importante é que isso ajudará você a acertar alguns problemas de lógica antecipadamente, e também evitará todas as substituições de código confuso. E você também enxergará o sistema de uma forma mais global, bem como poderá ajudar a modularizar seu código.

02. Declare claramente a estrutura da página

Trabalhar com um <div> principal é útil, mas trabalhar com <div> principal e com uma identificação representativa é ainda mais útil. Considere o seguinte cenário:

<div id="main-container">
<div id="header">
<div id="logo">...</div>
<div id="main-menu">...</div>
</div>
<div id="content">
<div id="left-column">...</div>
<div id="center-column">...</div>
<div id="right-column">...</div>
</div>
<div id="footer">
<div id="footer-menu">...</div>
<div id="disclaimer">...</div>
</div>
</div>

A organização da estrutura está evidente, graças aos recipientes DIV que recebem o id relativo ao conteúdo que será usado dentro dela. Não só ela é mais simples para começar a preencher, mas ele também vai ser perfeitamente transparente para alguém que tenta adicionar ou remover alguma coisa depois, facilitando muito o entendimento e manutenção do sistema.

03. Use identação

A identação mostra claramente a abertura e fechamento de pontos de cada elemento utilizado. Se cada linha de código está colado no lado esquerdo da tela, vai ser muito difícil distinguir o local exato onde um elemento está fechando. Portanto, isso vai atrapalhar o esforço em projetar uma estrutura completa, uma vez que não será perceptível mais tarde.

04. Escreva comentários explicativos

Subestimar o valor de bons comentários é desconsiderar uma maneira muito eficaz de documentação de código. É fácil, rápido e bem direto ao ponto, já que é feito ali mesmo enquanto você codifica.

Os comentários já escritos são igualmente eficientes, considerando o fato de que eles podem ser lidos no momento exato da dúvida. Eles podem, no entanto, ser usado em demasia. Tente sempre escrever comentários em pedaços de código onde não fica evidente qual é sua intenção do programa naquele momento do ponto de vista do negócio (ex.: usar um registro aleatório de um array pré-determinado, o que isso significa para o negócio?).

05. Evite abusar dos comentários

Os comentários não devem ser tratados como solução para código ruim. Ao comentar sobre o código, a funcionalidade atual deve ser descrita, bem como sua entrada e seu retorno. Aqui alguns exemplos de péssimos comentários:

• Escrever notas explicativas pra você mesmo: ( / * Vai terminar mais tarde … * /)

• Culpar coisas sobre outras pessoas: (/ * Sapão foi quem codificou isso. Se deu zica, pergunte a ele. */)

• Escrevendo declarações vagas: (/ * Esta é uma outra função matemática. */ )

• Apagar pedaços de código. Se você não tem certeza se deve apagar um determinado pedaço de código, comente-o. Às vezes um código complexo pode esconder soluções que você não vislumbra no primeiro momento. E se você apagar o código, fica mais difícil reverter alguma besteira que você fez. Eu comento códigos antigos regularmente 🙂

• /*C# é ótimo e Bill Gates é L33T0!*/ (sem comentários)

É bem melhor você comentar o código logo que estiver codificando e não deixar para depois, pois sem isso pode deixar seus colaboradores extremamente confuso.

Se o código será documentado através dos comentários (principalmente os embutidos: cabeçalho de classes, métodos, etc.), o pessoal que trabalha contigo precisa ter certeza que esses comentários estão lá por uma razão.

Exemplos de uso de bons comentários são:

• Registros de Criação e modificação (/* Criado por João, 13 de novembro de 2010 */)

• instruções detalhadas sobre a funcionalidade de um método ou procedimento (/* Esta função valida o formulário de login, com o auxílio da função check-mail */)

• descrição de alterações(/* Adicionado processo de validação de email */)

• palavras de sabedoria ( /*JornalJava is the best blog ever */)

6. Evite métodos com corpo gigaaaaaaantes

No processo de adicionar a funcionalidade de uma aplicação, os seus métodos tendem a crescer em número de linhas. Facilmente esses métodos podem crescer até algumas centenas de linhas de código, e isso tende a se tornar seu código confuso.

A melhor prática seria dividir os métodos grandes em menores. Alguns procedimentos podem mesmo estar se repetindo conforme você vai codificando (quantas vezes você já codificou um gerador de número aleatório, hein?). Você poderia fazer melhor uso desses procedimentos por meio de criação de funções distintas.

Bom, como esse assunto é altamente útil (e temos muitas dicas pra trocar sobre isso) em breve teremos mais artigos com algumas dicas de codificação!

Até a próxima!