Boas práticas de programação em Delphi
1. Cada método deve possuir no máximo 30 linhas (desde o cabeçalho até o último end do
método) que é o número de linhas visíveis no editor maximizado. Deve-se perseguir o
máximo de 10 linhas de código por método.
2. Cada método deve ter a complexidade máxima igual a 10.
3. A variável global de Form e DataModule criadas automaticamente pelo delphi devem
ser removidas das units desses, a menos que essa unit seja o form principal. Na
necessidade de se instanciar o form, deve-se declarar uma variável no código cliente.
4. Não referenciar o form principal em outros forms e classes.
5. Um form não poderá referenciar outro diretamente. Caso haja dependência entre os
dois essa dependência deve ser resolvida com propriedades e eventos e nunca com
referência direta.
6. Submetodos (procedures e funções dentro de procedures e funções) devem ser
evitados.
7. Antes de acessar um dado de uma determinada classe, pergunte se o processamento
pode ser realizado pela própria classe. Da mesma forma ao projetar uma classe,
antes de criar propriedades, verifique a possibilidade dessa classe absorver todo o
processamento realizado com essa variável (principio Tell, Don’t ask)
8. Não usar parâmetros como se fossem variáveis, a menos que o parâmetro seja um var
e receberá um valor de saída que será utilizado pela rotina chamadora, do contrário
declare parâmetros como constantes usando a palavra const.
9. Antes de começar a codificar qualquer coisa, verificar se já não existe, na lib, no delphi
ou no próprio sistema algum recurso ou funcionalidade que realize esse trabalho.Evitar
toda e qualquer duplicidade de código, tela e recursos.
10. Ao projetar classes e novos recursos, nunca faça isso sozinho. Tenha sempre a
participação de outro programador (e se possível de um analista de qualidade) e o
conhecimento e aprovação da sua equipe de programação.
11. Caso encontre dados que sempre estão juntos (por exemplo Rua, Número,Bairro,
Cidade...) sempre considere a possibilidade de se criar uma classe (TEndereco).
12. Não tenha expectativas a respeito do funcionamento interno (implementação) de
outra classe mesmo que você tenha acesso aos fontes dessa. Por exemplo, se ao
chamar um método, você sabe que ele coloca uma tabela no primeiro registro, não
codifique esperando esse comportamento sempre, pois ele pode mudar e quebrar o seu
código.Codifique como se não conhecesse o comportamento das classes.
13. Utilize apenas os métodos necessários para o funcionamento do código. Por exemplo:
Errado:
var
q :TSetupQuery;
begin
q := TSetupQuery.Create(‘WPHD’);
try
q.Close(); <- desnecessário
q.SQL.Clear() <- desnecessário
q.SQL.Add('select * from teste');
q.Open();
result := q.Fieds.FieldByName('id').AsString;
faltando um close aqui
finally
q.free();
end;
end;
Certo:
var
q: TSetupQuery;
begin
q := TSetupQuery.Create(‘TESTE’);
try
q.SQL.Add('select * from teste');
q.Open();
result := q.Fieds.FieldByName('id').AsString;
q.Close();
finally
q.free();
end;
end;
14. Declare suas variáveis com o menor escopo possível, ou seja, suas variáveis devem
estar dentro de métodos e somente em caso de necessidade, terem o escopo
aumentado para private. Variáveis public e globais devem ser evitadas.
15. Evite reusar a mesma variável para diversas funções. Encapsule processamentos
separados em métodos separados e cada método com sua variável.
16. Evite variáveis de estado nos métodos.
17. Evite rotinas muito profundas, com vários condicionais aninhados.
18. Não utilize try...except...end vazio.
19. Não utilize try..finally...end vazio.
20. Ao trabalhar com objetos SEMPRE utilize try..finally...end.
21. Não coloque código no finally que não seja código de limpeza (objeto.free).
22. Não utilize comentários para separar blocos de código. Comente apenas como forma de
documentação.
23. Crie apenas uma classe por unit, salvo quando as classes possuirem referência circular.
24. Não utilize “if” vazio. Prefira usar o not.
25. Evite usar with. Sempre declare suas variáveis de instância.
26. Evite usar datamodules. Prefira instanciar os objetos não-visuais em runtime.
27. Evite concatenar strings. Prefira usar o format.
28. Reduza o número de parâmetros dos métodos.
29. Reduza o número de métodos por classe.
30. Reduza o número de classes por projeto.
31. Reduza o número de componentes nas telas.
32. Reduza o tráfego de objetos no código.
33. Coloque Comandos e Pesquisas em métodos separados. Comandos são os métodos
que executam uma ação (procedures), pesquisas são métodos que retornam um valor
(funções). Em resumo evite métodos com “efeitos colaterais”. Por exemplo, funções que
exibem telas de cadastro ao não encontrar um determinado registro (principio Query
and Command separation).
34. Centralize seu processamento em classes muito bem modeladas. Evite ter que revalidar
as mesmas informações em pontos diferentes.
35. Prefira tratar exceções (except) do que fazer verificações.
36. Não capture exceções genéricas (except) sempre capture as mais especificas de
acordo com a situação.
37. Nunca capture exceções para exibi-las em uma caixa de diálogo, salvo quando essa
exceção já carrega uma mensagem especifica da situação.
38. Sempre crie a sua “família de exceções” de acordo com a Entidade e a funcionalidade.
Nunca lance Exception diretamente.
39. Caixas de diálogo (MessageDlg, ShowMessages e MessageBox) só devem ser
chamadas na interface com o usuário GUI. Evite ter essas chamadas dentro de classes
de negócios. Prefira lançar exceções.
40. Não comente explicando o código. Comente explicando o motivo do código estar ali.
41. Não comente explicando o código. Torne o código óbvio.
42. Utilize métodos não apenas para reaproveitar código, mas também para:
● Separar blocos de código relacionados;
● Documentar;
43. Evite parâmetros padrão, prefira usar sobrecarga de métodos.
