Nomes
Escolher nomes significativos para variáveis, métodos e classes não parece importante para programadores inexperientes. Apenas quando alguém tentar ler algum código onde os nomes das classes e variáveis não são representativos é que se nota a importância
deste tópico.
As classes representam entidades no domínio do problema, e os métodos algum comportamento. Por isso nomes de variáveis e de classes devem estar relacionados com as entidades que elas representam e nomes de métodos devem refletir a sua ação.
Colocar junto à declaração de cada variável uma explicação
da sua função (o que ela representa?), e se possível as
situaçãoes em que ela é usada.
É uma má prática escolher nomes complicados ou não-relacionados. É também má prática usar o mesmo nome para diferentes propósitos
Aninhamento
Diferentes estruturas de controle, em particular o if-then-else,
podem ser aninhadas. Se o aninhamento começa a ficar profundo (formando uma árvore de estruturas), os programas ficam mais difíceis de entender. No caso de um aninhamento profundo de
comandos if-then-else, é difícil determinar a que if
pertence um certo else.
Onde for possível, o aninhamento profundo deve ser evitado. Até mesmo se isso representar uma pequena ineficiência. Por exemplo, considere a construção abaixo.
if (C1) {S1}
else {
if (C2) {S2}
else {
if (C3) {S3}
else {
if (C4) {S4}
}
}
}
Se as diferentes condições são disjuntas (O que geralmente acontece) então esta estrutura pode ser convertida na seguinte estrutura:
if (C1) {S1};
if (C2) {S2};
if (C3) {S3};
if (C4) {S4};
Esta construção é um pouquinho menos eficiente que a primeira, mas bem mais fácil de entender. Em geral, se o preço a se pagar pela simplicidade é apenas uma pequena ineficiência, é mais desejável evitar o aninhamento profundo.
Tamanho de Métodos
Esta é uma questão mais ligada ao projeto do sistema como um todo, mas os programadores devem se lembrar que o código de linguagens orientadas a objetos têm uma probabilidade bem maior de ser usado por outras pessoas, por isso ele deve estar bem estrutura
do e coeso.
Um programa com poucos métodos muito grandes (mais de 50 estruturas) muitas vezes causa uma falta de coesão funcional e uma grande quantidade de módulos muito pequenos (menos de 5 estruturas) pode causar um overhead desnecessário.
Um código de qualquer módulo não deve ocupar mais do que uma página
de tela. é fundamental conseguir visualizar o código todo (do modulo) de
uma só vez para o seu total entendimento. O ideal é que cada método
cuide de uma função simples. Se estiver muito loingo, é sinal que ele
poderia ser dividido, reduzindo sua complexidade e facilitando a compreeensãoe o reuso.
Como não há uma regra
direta e rápida que trate de tamanho de métodos, alguns princípios a serem seguidos são coesão e acoplamento entre métodos.
Interface entre Métodos
Um método que tem uma interface (definição) complexa deve ser cuidadosamente examinado. Tais métodos podem não estar funcionalmente coesos e podem estar realizando múltiplas funções.
Qualquer método com mais de cinco parâmetros deve ser cuidadosamente examinado e quebrado em vários métodos com uma interface (definição) mais simples, se possível.
Layout do Programa
Como o programa está implementado e apresentado pode ter um grande efeito no entendimento do mesmo. Identação, comentários, parênteses, etc, devem ser usados com a intenção de tornar o código mais claro.
Efeitos Colaterais
Quando um método é invocado, ele às vezes tem efeitos colaterais que podem modificar o estado do sistema através da alteração dos parâmetros listados na sua definição, como por exemplo, modificando variáveis globais.
As modificações efetuadas nos elementos de um objeto devem se restringir aos métodos a ele associados (encapsulamento).
Robustez
Um programa é robusto se ele faz algo planejado até para condições excepcionais. Um programa pode encontrar condições excepcionais na forma de entradas erradas, valor incorreto de alguma variável, overflow, ou algum erro mais sério que levante uma exceção . O programa deve tentar tratar tais situações. Em geral, deve checar a corretude das entradas, onde for possível, etc. Se tais condições ocorrerem, o programa não deve travar a máquina ou gerar um core, e sim produzir alguma mensagem de erro significativa e sair normalmente.
Breno Gustavo Soares da Costa, bgsc@di.ufpe.br