Mudanças entre as edições de "Delphi"
Linha 1: | Linha 1: | ||
Endentação | :Endentação | ||
Margens | Dois espaços por nível | ||
Não usar caracter de tabulação, desmarque "use tab character" e "otimal fill" nas opções do Delphi, "Editor Options" / "Source Options" | |||
:Margens | |||
Usar máximo 170 e mínimo 120 | |||
:begin-end | |||
"begin" sempre na linha de baixo, exceção quando quando precedido de "else". | |||
begin | Exemplo: | ||
// incorreto | |||
for i:= 0 to 10 begin | |||
// correto | |||
for i:= 0 to 10 | |||
begin | |||
[..] | |||
end | |||
else | |||
begin | |||
[..] | |||
end; | |||
:Parêntese | |||
Não usar espaço entre um parêntese inicial e o caráter seguinte. | |||
Exemplo: | |||
// incorreto | |||
FuncaoTeste( Valor ); | |||
// correto | |||
FuncaoTeste(Valor); | |||
:Palavras reservadas | |||
Usar sempre toda em letra minúscula. | |||
Exemplo: | |||
// incorreto | |||
If True THEN | |||
Begin | |||
End; | |||
// correto | |||
if True then | |||
begin | |||
end; | |||
Procedimentos e Funções | :Procedimentos e Funções | ||
Nomeação: | |||
Nomeação: | |||
Usar nomes que remetem a sua funcionalidade, isso evita ter que ler todo o código para saber o que ele faz. | Usar nomes que remetem a sua funcionalidade, isso evita ter que ler todo o código para saber o que ele faz. | ||
Usar nomes em português (preferencialmente no infinitivo) | |||
Não utilizar caracteres especiais, exemplo: ç, á, etc. | |||
Usar primeira letra maiúscula nas palavras e o restante minúsculo. | |||
Exemplo: | |||
// incorreto | |||
procedure carregarbloqueiocampos; | |||
// correto | |||
procedure CarregarBloqueioCampos; | |||
Usar nomes que remete a sua funcionalidade e a que se aplica | |||
Exemplo: | |||
procedure SomarValores; | |||
Ação: Somar | |||
Aplica-se a: Valores | |||
Rotinas que remetem uma ação usar verbo antes | |||
Exemplo: | |||
procedure SomarValores; | |||
Só criar métodos que serão usados. Não adicionar pensando que um dia será usado. | |||
A principal finalidade dos métodos é a reutilização de códigos. Só criá-los se forem chamados mais de uma vez. Para agrupamento de blocos de códigos executados uma única vez use comentários ou regiões; | |||
Não criar métodos com apenas uma linha de código, exceto se a situação exigir. Exemplo disso são os métodos de GET e SET, métodos primitivos que devem ser sobrescritos em classes filhas e métodos remotos (declarados com interface). | |||
Verificar o escopo de utilização do método (private, públic, ...), procurando criar dentro da unit/classe mais adequada ou mesmo como subfunções. | |||
Ao desenvolver um método, pensar na melhor forma de receber os parâmetros e de retornar o valor. De forma a ter um maior reaproveitamento do código evitando a criação de outros métodos com funções parecidas. | |||
Efetuar a documentação do método no Header, seguindo os padrões de documentação da IDE. | |||
Ao criar métodos com sobrecarga(overload) manter a mesma ordem e nome de parâmetros, quando possível, facilitando a identificação de qual deles usar. | |||
Evitar criar métodos longos demais, que executam diversas coisas ao mesmo tempo. Pois se tornam, praticamente, não reutilizáveis. Ou se for reutilizável, você terá que ler todo o conteúdo para saber se é exatamente o que quer. Se o método já estiver muito longo, pense em refatorá-lo (dividi-lo em várias partes). | |||
Quando desenvolver uma versão melhorada de um método, ver se há possibilidade de substituição da utilização dele em todo o sistema. Somente em último caso criar outro método, e nesse caso, ver a possibilidade de usar um chamamento ao já existente. | |||
Parâmetros de Procedimentos e Funções | Parâmetros de Procedimentos e Funções | ||
Nomeação: | |||
Usar nomes que remetem a sua funcionalidade. | |||
Usar nomes em português. | |||
Agrupar parâmetros dos mesmos tipos. | |||
Exemplo: | |||
procedure SomarValores(Valor1, Valor2: integer); | |||
A ordem dos parâmetros: | |||
Dos mais utilizados para os menos utilizados | |||
Entrada deverá vir antes dos de saída | |||
Genéricos antes de específicos | |||
Exceção: Em manipuladores de evento "Sender" do tipo "TObject" é primeiro | |||
Quando parâmetro não é modificado usar "const", com isso garante que não haverá modificação e o compilador gera um código mais eficiente. | |||
Ao usar uma função informar sua origem, assim evita ambiguidade. | Ao usar uma função informar sua origem, assim evita ambiguidade. | ||
Exemplo: | |||
// incorreto | |||
IfThen(Condicao, 0, 1); | |||
IfThen(Condicao, 'S', 'N'); | |||
// correto | |||
System.Math.IfThen(Condicao, 0, 1); | |||
System.StrUtils.IfThen(Condicao, 'S', 'N'); | |||
Uses | |||
:Uses | |||
Declarar na uses da interface apenas se estiver usando os tipos existentes na classe na declaração. Além de manter o código ligeiramente mais organizado e evitar problemas do compilador acusar que há uma referência cíclica entre as units (duas units que se referem no Uses de Interface). | |||
Variáveis | :Variáveis | ||
Nomeação: | |||
Usar nomes que remetem a sua funcionalidade e significado. | |||
Usar nomes em português. | |||
Não criar com nomes muito pequenos e comuns de serem usados em outros locais do sistema, como por exemplo: Cor, Variacao... Preferir nomes mais longos e descritivos como: LancaVariacaoDetalheEntrada, SistemaTrabalhaComCor | Não criar com nomes muito pequenos e comuns de serem usados em outros locais do sistema, como por exemplo: Cor, Variacao... Preferir nomes mais longos e descritivos como: LancaVariacaoDetalheEntrada, SistemaTrabalhaComCor | ||
Exceção: em variáveis usadas em iteração, usado único caráter, exemplo: I, J ou K | |||
Uso de variáveis globais não é recomendado, mas se necessário mantenha no contexto que é utilizada. | |||
:Tipos | |||
Tipos que são palavras reservados, assim segue orientação anterior de ser completamente minúscula. | |||
Exceção: Tipo da API do Win32 | |||
Exemplo: | |||
var | |||
Mensagem: string; // palavra reservada | |||
WindowsHandle: HWND; // tipo da API do Win21 | |||
:Tipos de ponto flutuante | |||
Não utilize "Real", descontinuado, mantido apenas para compatibilidade com códigos antigos do Pascal, use "Double". | |||
Evite usar "Extended", use apenas se houver necessidade de uma facha maior do que oferecidas por "Double", para "Double" as instruções do processador são mais otimizadas sendo também formato padrão definido pelo IEEE; | |||
Usar "Single" apenas quando o tamanho físico dos bytes da variável de ponto flutuante for significativo, como ao usar DLL'S de outras linguagens; | |||
Tipos | :Tipos enumerados | ||
Nomeação: | |||
Usar nomes que remetem a seu significado | |||
Usar nomes em português | |||
Usar prefixo "T" | |||
Na lista de identificadores do tipo deverá conter um prefixo de dois ou três caracteres minúsculos que o relacione ao nome do tipo enumerado original. | |||
Exemplo: | |||
TTipoMusica = (stRock, stClassical, stCountry) | |||
Tipos | :Tipos array e registro | ||
Nomeação: | |||
Usar nomes que remetem a sua finalidade | |||
Usar nomes em português | |||
Instrução if | Usar prefixo "T" | ||
Exemplo: | |||
TArrayCiclo = array[1..100] of integer; | |||
TFuncionario = record | |||
Nome: string; | |||
Salario: Double; | |||
end; | |||
:Instrução if | |||
Evite negar a expressão, dificulta a leitura do código. | |||
Na cláusula "then" coloque o caso mais provável, e no "else" o menos provável, sempre que possível ou for a parte mais interna de um algoritmo repetido inúmeras vezes. | |||
Sempre que possível utilize "case" ao invés de "if", evita encadeamentos. | |||
Exemplo: | |||
// incorreto | |||
if not true then | |||
x := 0 | |||
else | |||
x := 1; | |||
// correto | |||
if true then | |||
x := 1 | |||
else | |||
x := 0; | |||
Não utilize expressões com mais de cinco níveis de profundidade, crie método para isso. | |||
Se várias condições estiverem sendo testadas, as condições devem estar organizadas da esquerda para direita na ordem de intensidade de cálculos, da menor para maior. Assim permite que o código aproveite a lógica da avaliação boolean de curto circuito embutida no compilador. | |||
Prefira a estrutura básica da linguagem a funções específicas | |||
Exemplo: | |||
// incorreto | |||
Flag := iif(bProporcional, bCalcula, False); | |||
// correto | |||
Flag := bProporcional and bCalcula; | |||
Evitar duplo ‘IF’ onde da para usar ‘and’. | |||
Exemplo: | |||
if (Tipo = Pagar) then | |||
if OcultarRegistro then | |||
:Instrução case | |||
As instruções de caso devem ser simples e geralmente não exceder cinco linhas, se for complexas melhor criar uma procedure. | |||
A cláusula "else" deve ser usada apenas para detectar erros. | |||
Não usar para apenas uma condição | |||
Exemplo: | |||
// incorreto | |||
case CodigoTabela of | |||
1: ImportarTabelaAjuste; | |||
end; | |||
:Instrução with | |||
Usar com prudência e atenção, evite uso demasiado de instruções e vários objetos, etc.. | |||
Exemplo: | |||
// muito arriscado o uso | |||
with CDS, Registro, Edit1 do | |||
begin | |||
[..] | |||
with Edit2 do | |||
begin | |||
[..] | |||
end; | |||
end; | |||
:Uso de try..finnaly | |||
Utilizado para garantir a deslocação correta de recurso | |||
Exemplo: | |||
// incorreto | |||
try | |||
Objeto := TObjeto.Create; | |||
[..] | |||
finally | |||
Objeto.Free; | |||
end; | |||
// correto | |||
Objeto := TObjeto.Create; | |||
try | |||
[..] | |||
finally | |||
Objeto.Free; | |||
end; | |||
:Uso de try..except | |||
Utilize APENAS quando quiser realizar alguma tarefa se surgir à exceção; | |||
Não utilize apenas para mostrar uma mensagem de erro, isso será feito automaticamente no contexto da aplicação; | |||
De forma alguma substitua a mensagem original de erro uma alguma mensagem que você pense que irá ocorrer, pode ocorrer outro erro e nunca saber a mensagem de erro original; | |||
:Classes | |||
Uso de try..except | Nomeação: | ||
Usar nomes que remetem a sua finalidade | |||
Usar nomes em português. | |||
Usar prefixo "TClass" . | |||
Usar elementos privados. Para se tornarem visíveis de fora, utilizar propriedades; | Usar elementos privados. Para se tornarem visíveis de fora, utilizar propriedades; | ||
Exemplo: | |||
Type | |||
TClassCliente = Class(TObject) | |||
Para instância usar “T” mais o primitivo de classe | Para instância usar “T” mais o primitivo de classe | ||
Exemplo: | |||
Var | |||
TCliente: TClassCliente; | |||
Colocar os eventos de criação de destruição antes dos demais | Colocar os eventos de criação de destruição antes dos demais | ||
Projetos | :Propriedades | ||
Nomeação/Formatação: | |||
Nomes iguais aos campos que elas representam, sem o indicador “F”. | |||
Usar substantivo e não verbos. Representam dados, os métodos que representam ações; | |||
Array deverão estar no plural, restante no singular; | |||
:Projetos | |||
Sempre que efetuar modificações feche o projeto no Delphi, faça um “Check Out” poderá haver uma confirmação de se deseja sobrepor o atual, coloque sim, por garantia pode dar um “get”; | Sempre que efetuar modificações feche o projeto no Delphi, faça um “Check Out” poderá haver uma confirmação de se deseja sobrepor o atual, coloque sim, por garantia pode dar um “get”; | ||
Formulários | |||
:Formulários | |||
Nomeação | |||
Usar nomes que remetem a sua finalidade | |||
Usar nomes em português | |||
Usar prefixo "F" | |||
Não ultrapassar o tamanho limite de 790 x 500, com exceção de tela principal. Tamanhos superiores dificultam o uso em resoluções de 800 x 600, exemplo: demonstração com Datashow; | |||
Sempre que adicionado ao projeto lembre-se de adicionar em todos os DPR’s que fazem referencia. | Sempre que adicionado ao projeto lembre-se de adicionar em todos os DPR’s que fazem referencia. | ||
Ao criar formulários herdados, verificar a utilidade para todo o sistema e não apenas a um módulo. | |||
Colocar os eventos de criação de destruição antes dos demais | Colocar os eventos de criação de destruição antes dos demais | ||
Módulos de dados | |||
:Módulos de dados | |||
Nomeação: | |||
Usar nomes que remetem a sua finalidade, geralmente acompanha nome do formulário. | |||
Usar nomes em português | Usar nomes em português | ||
Usar prefixo "DM" | |||
Colocar os eventos de criação de destruição antes dos demais | Colocar os eventos de criação de destruição antes dos demais | ||
Unidade de código | |||
:Unidade de código | |||
Nomeação | |||
Usar nomes que remetem a sua finalidade | |||
Usar nomes em português | |||
Colocar os eventos de criação de destruição antes dos demais | Colocar os eventos de criação de destruição antes dos demais | ||
Pacotes | |||
:Pacotes | |||
Nomeação | |||
Usar nomes que remetem a seu significado | |||
Usar nomes em português | |||
Incluir em diretório separado de um projeto, para distinguir de unidades. | Incluir em diretório separado de um projeto, para distinguir de unidades. | ||
Colocar os eventos de criação de destruição antes dos demais | Colocar os eventos de criação de destruição antes dos demais | ||
Componentes | :Componentes | ||
Todos os componentes deverão ter nomes descritivos, nenhum componente deverá ficar com nome padrão atribuído a eles pelo Delphi, deverá conter um prefixo de acordo com tipo conforme abaixo e o qualificador: | |||
Tabela de prefixos: | |||
Prefixo Tipo de Objeto | |||
ani Animate | |||
bar StatusBar, TrackBar, ToolBar, CoolBar | |||
btn Button, BitBtn, SpeedButton, ToolButton | |||
bvl Bevel | |||
cal Calendar, DateTimePicker | |||
cb ComboBox, DBComboBox | |||
cds ClientDataSet | |||
cx CheckBox, DbCheckBox | |||
cht Chart, DBChart, DecisionGraph | |||
ckl CheckListBox | |||
crs TcriticalSection | |||
csk ClientSocket | |||
cub DecisionCub | |||
idb DataBase | |||
dlg Dialogs (Open, Save, etc) | |||
dm DataModule | |||
ds DataSource, DecisionSource | |||
edt Edit, DBEdit, SpinEdit | |||
evt TEvent, TSimpleEvent | |||
F Form | |||
grd StringGrid, DrawGrid, DBGrid | |||
gb GroupBox | |||
iml ImageList | |||
img Image | |||
lbl Label, DBText, StaticText | |||
lbx ListBox, DBListBox | |||
lst List | |||
lvw ListView | |||
mmo Memo, DBMemo, RichEdit, DBRichEdit | |||
mit MenuItem | |||
mmn MainMenu | |||
nav DBNavigator | |||
nbk Notebook | |||
pbr ProgressBar | |||
pbx Paintbox | |||
pnl Panel | |||
qry Query | |||
rbt RadioButton | |||
rg RadioGroup | |||
rpt Report | |||
O qualificador deverá descrever a finalidade do componente; | |||
Exemplo: | |||
btnFecharForm | |||
:Repositório (JEDI) | |||
Sempre que adicionar uma unit ao DPR lembre-se enviar para o repositório. | Sempre que adicionar uma unit ao DPR lembre-se enviar para o repositório. | ||
Só enviar para o servidor (CheckIn) conjunto de units que estejam, no mínimo, compiláveis. | Só enviar para o servidor (CheckIn) conjunto de units que estejam, no mínimo, compiláveis. | ||
JEDI: vídeo-aulas disponíveis em \\dataserver\Estudo\Video Aula JEDI. | JEDI: vídeo-aulas disponíveis em \\dataserver\Estudo\Video Aula JEDI. | ||
Geral | :Transação | ||
Ao testar o contexto da transção não utilizar “InTransaction”, usar “HasTransaction”, InTransaction verificar apenas se há um transação, HasTransaction já verifica se aquela transação realmente é a ultima empilhada. | |||
Evite abrir muitas transações, torna-se o processo mais lento. | |||
:Geral | |||
Não deixar hints (acidentais) ou warnings pendentes. Em último caso, fazer uso de diretivas de compilação para torná-los sem efeito. | Não deixar hints (acidentais) ou warnings pendentes. Em último caso, fazer uso de diretivas de compilação para torná-los sem efeito. | ||
Só adicionar uma unit na seção uses, na plena certeza da sua necessidade. Quanto mais dependências existirem entre as units, menos chance de ser reaproveitada em outro módulo ou projeto haverá. | Só adicionar uma unit na seção uses, na plena certeza da sua necessidade. Quanto mais dependências existirem entre as units, menos chance de ser reaproveitada em outro módulo ou projeto haverá. | ||
Não inclua códigos demorados na seção “Inicialization”, isso fará com que a aplicação pareça ser lenta logo na partida; Caso tenha alocados itens na seção “Inicialization” não esqueça de desalocar na seção “finalization”; | Não inclua códigos demorados na seção “Inicialization”, isso fará com que a aplicação pareça ser lenta logo na partida; Caso tenha alocados itens na seção “Inicialization” não esqueça de desalocar na seção “finalization”; | ||
Fazer uso de constantes gerais e das classes de sistema, evitar deixar valores travados, dificulta a rastreio de manutenção | Fazer uso de constantes gerais e das classes de sistema, evitar deixar valores travados, dificulta a rastreio de manutenção |
Edição das 12h10min de 4 de outubro de 2022
- Endentação
Dois espaços por nível Não usar caracter de tabulação, desmarque "use tab character" e "otimal fill" nas opções do Delphi, "Editor Options" / "Source Options"
- Margens
Usar máximo 170 e mínimo 120
- begin-end
"begin" sempre na linha de baixo, exceção quando quando precedido de "else".
Exemplo: // incorreto for i:= 0 to 10 begin
// correto for i:= 0 to 10 begin [..] end else
begin [..]
end;
- Parêntese
Não usar espaço entre um parêntese inicial e o caráter seguinte. Exemplo: // incorreto FuncaoTeste( Valor );
// correto FuncaoTeste(Valor);
- Palavras reservadas
Usar sempre toda em letra minúscula. Exemplo: // incorreto If True THEN Begin End;
// correto if True then begin end;
- Procedimentos e Funções
Nomeação:
Usar nomes que remetem a sua funcionalidade, isso evita ter que ler todo o código para saber o que ele faz.
Usar nomes em português (preferencialmente no infinitivo)
Não utilizar caracteres especiais, exemplo: ç, á, etc.
Usar primeira letra maiúscula nas palavras e o restante minúsculo.
Exemplo: // incorreto procedure carregarbloqueiocampos;
// correto procedure CarregarBloqueioCampos;
Usar nomes que remete a sua funcionalidade e a que se aplica
Exemplo: procedure SomarValores; Ação: Somar Aplica-se a: Valores
Rotinas que remetem uma ação usar verbo antes
Exemplo:
procedure SomarValores;
Só criar métodos que serão usados. Não adicionar pensando que um dia será usado.
A principal finalidade dos métodos é a reutilização de códigos. Só criá-los se forem chamados mais de uma vez. Para agrupamento de blocos de códigos executados uma única vez use comentários ou regiões;
Não criar métodos com apenas uma linha de código, exceto se a situação exigir. Exemplo disso são os métodos de GET e SET, métodos primitivos que devem ser sobrescritos em classes filhas e métodos remotos (declarados com interface).
Verificar o escopo de utilização do método (private, públic, ...), procurando criar dentro da unit/classe mais adequada ou mesmo como subfunções.
Ao desenvolver um método, pensar na melhor forma de receber os parâmetros e de retornar o valor. De forma a ter um maior reaproveitamento do código evitando a criação de outros métodos com funções parecidas.
Efetuar a documentação do método no Header, seguindo os padrões de documentação da IDE.
Ao criar métodos com sobrecarga(overload) manter a mesma ordem e nome de parâmetros, quando possível, facilitando a identificação de qual deles usar.
Evitar criar métodos longos demais, que executam diversas coisas ao mesmo tempo. Pois se tornam, praticamente, não reutilizáveis. Ou se for reutilizável, você terá que ler todo o conteúdo para saber se é exatamente o que quer. Se o método já estiver muito longo, pense em refatorá-lo (dividi-lo em várias partes).
Quando desenvolver uma versão melhorada de um método, ver se há possibilidade de substituição da utilização dele em todo o sistema. Somente em último caso criar outro método, e nesse caso, ver a possibilidade de usar um chamamento ao já existente.
Parâmetros de Procedimentos e Funções
Nomeação: Usar nomes que remetem a sua funcionalidade.
Usar nomes em português.
Agrupar parâmetros dos mesmos tipos.
Exemplo:
procedure SomarValores(Valor1, Valor2: integer);
A ordem dos parâmetros:
Dos mais utilizados para os menos utilizados
Entrada deverá vir antes dos de saída
Genéricos antes de específicos
Exceção: Em manipuladores de evento "Sender" do tipo "TObject" é primeiro
Quando parâmetro não é modificado usar "const", com isso garante que não haverá modificação e o compilador gera um código mais eficiente.
Ao usar uma função informar sua origem, assim evita ambiguidade. Exemplo: // incorreto IfThen(Condicao, 0, 1); IfThen(Condicao, 'S', 'N');
// correto System.Math.IfThen(Condicao, 0, 1); System.StrUtils.IfThen(Condicao, 'S', 'N');
- Uses
Declarar na uses da interface apenas se estiver usando os tipos existentes na classe na declaração. Além de manter o código ligeiramente mais organizado e evitar problemas do compilador acusar que há uma referência cíclica entre as units (duas units que se referem no Uses de Interface).
- Variáveis
Nomeação:
Usar nomes que remetem a sua funcionalidade e significado.
Usar nomes em português.
Não criar com nomes muito pequenos e comuns de serem usados em outros locais do sistema, como por exemplo: Cor, Variacao... Preferir nomes mais longos e descritivos como: LancaVariacaoDetalheEntrada, SistemaTrabalhaComCor
Exceção: em variáveis usadas em iteração, usado único caráter, exemplo: I, J ou K
Uso de variáveis globais não é recomendado, mas se necessário mantenha no contexto que é utilizada.
- Tipos
Tipos que são palavras reservados, assim segue orientação anterior de ser completamente minúscula.
Exceção: Tipo da API do Win32
Exemplo:
var
Mensagem: string; // palavra reservada WindowsHandle: HWND; // tipo da API do Win21
- Tipos de ponto flutuante
Não utilize "Real", descontinuado, mantido apenas para compatibilidade com códigos antigos do Pascal, use "Double".
Evite usar "Extended", use apenas se houver necessidade de uma facha maior do que oferecidas por "Double", para "Double" as instruções do processador são mais otimizadas sendo também formato padrão definido pelo IEEE;
Usar "Single" apenas quando o tamanho físico dos bytes da variável de ponto flutuante for significativo, como ao usar DLL'S de outras linguagens;
- Tipos enumerados
Nomeação:
Usar nomes que remetem a seu significado
Usar nomes em português
Usar prefixo "T"
Na lista de identificadores do tipo deverá conter um prefixo de dois ou três caracteres minúsculos que o relacione ao nome do tipo enumerado original.
Exemplo:
TTipoMusica = (stRock, stClassical, stCountry)
- Tipos array e registro
Nomeação:
Usar nomes que remetem a sua finalidade
Usar nomes em português
Usar prefixo "T"
Exemplo:
TArrayCiclo = array[1..100] of integer; TFuncionario = record Nome: string;
Salario: Double;
end;
- Instrução if
Evite negar a expressão, dificulta a leitura do código.
Na cláusula "then" coloque o caso mais provável, e no "else" o menos provável, sempre que possível ou for a parte mais interna de um algoritmo repetido inúmeras vezes.
Sempre que possível utilize "case" ao invés de "if", evita encadeamentos.
Exemplo:
// incorreto if not true then x := 0 else x := 1;
// correto if true then
x := 1
else
x := 0;
Não utilize expressões com mais de cinco níveis de profundidade, crie método para isso.
Se várias condições estiverem sendo testadas, as condições devem estar organizadas da esquerda para direita na ordem de intensidade de cálculos, da menor para maior. Assim permite que o código aproveite a lógica da avaliação boolean de curto circuito embutida no compilador.
Prefira a estrutura básica da linguagem a funções específicas
Exemplo:
// incorreto Flag := iif(bProporcional, bCalcula, False);
// correto Flag := bProporcional and bCalcula;
Evitar duplo ‘IF’ onde da para usar ‘and’.
Exemplo:
if (Tipo = Pagar) then if OcultarRegistro then
- Instrução case
As instruções de caso devem ser simples e geralmente não exceder cinco linhas, se for complexas melhor criar uma procedure.
A cláusula "else" deve ser usada apenas para detectar erros.
Não usar para apenas uma condição
Exemplo:
// incorreto case CodigoTabela of 1: ImportarTabelaAjuste; end;
- Instrução with
Usar com prudência e atenção, evite uso demasiado de instruções e vários objetos, etc..
Exemplo:
// muito arriscado o uso with CDS, Registro, Edit1 do begin [..]
with Edit2 do begin [..] end;
end;
- Uso de try..finnaly
Utilizado para garantir a deslocação correta de recurso
Exemplo:
// incorreto try Objeto := TObjeto.Create;
[..]
finally Objeto.Free; end;
// correto Objeto := TObjeto.Create; try [..] finally Objeto.Free; end;
- Uso de try..except
Utilize APENAS quando quiser realizar alguma tarefa se surgir à exceção;
Não utilize apenas para mostrar uma mensagem de erro, isso será feito automaticamente no contexto da aplicação;
De forma alguma substitua a mensagem original de erro uma alguma mensagem que você pense que irá ocorrer, pode ocorrer outro erro e nunca saber a mensagem de erro original;
- Classes
Nomeação:
Usar nomes que remetem a sua finalidade
Usar nomes em português.
Usar prefixo "TClass" .
Usar elementos privados. Para se tornarem visíveis de fora, utilizar propriedades;
Exemplo:
Type TClassCliente = Class(TObject)
Para instância usar “T” mais o primitivo de classe
Exemplo:
Var TCliente: TClassCliente;
Colocar os eventos de criação de destruição antes dos demais
- Propriedades
Nomeação/Formatação:
Nomes iguais aos campos que elas representam, sem o indicador “F”.
Usar substantivo e não verbos. Representam dados, os métodos que representam ações;
Array deverão estar no plural, restante no singular;
- Projetos
Sempre que efetuar modificações feche o projeto no Delphi, faça um “Check Out” poderá haver uma confirmação de se deseja sobrepor o atual, coloque sim, por garantia pode dar um “get”;
- Formulários
Nomeação
Usar nomes que remetem a sua finalidade
Usar nomes em português
Usar prefixo "F"
Não ultrapassar o tamanho limite de 790 x 500, com exceção de tela principal. Tamanhos superiores dificultam o uso em resoluções de 800 x 600, exemplo: demonstração com Datashow;
Sempre que adicionado ao projeto lembre-se de adicionar em todos os DPR’s que fazem referencia.
Ao criar formulários herdados, verificar a utilidade para todo o sistema e não apenas a um módulo.
Colocar os eventos de criação de destruição antes dos demais
- Módulos de dados
Nomeação:
Usar nomes que remetem a sua finalidade, geralmente acompanha nome do formulário.
Usar nomes em português
Usar prefixo "DM"
Colocar os eventos de criação de destruição antes dos demais
- Unidade de código
Nomeação
Usar nomes que remetem a sua finalidade
Usar nomes em português
Colocar os eventos de criação de destruição antes dos demais
- Pacotes
Nomeação
Usar nomes que remetem a seu significado
Usar nomes em português
Incluir em diretório separado de um projeto, para distinguir de unidades.
Colocar os eventos de criação de destruição antes dos demais
- Componentes
Todos os componentes deverão ter nomes descritivos, nenhum componente deverá ficar com nome padrão atribuído a eles pelo Delphi, deverá conter um prefixo de acordo com tipo conforme abaixo e o qualificador:
Tabela de prefixos:
Prefixo Tipo de Objeto ani Animate bar StatusBar, TrackBar, ToolBar, CoolBar btn Button, BitBtn, SpeedButton, ToolButton bvl Bevel cal Calendar, DateTimePicker cb ComboBox, DBComboBox cds ClientDataSet cx CheckBox, DbCheckBox cht Chart, DBChart, DecisionGraph ckl CheckListBox crs TcriticalSection csk ClientSocket cub DecisionCub idb DataBase dlg Dialogs (Open, Save, etc) dm DataModule ds DataSource, DecisionSource edt Edit, DBEdit, SpinEdit evt TEvent, TSimpleEvent F Form grd StringGrid, DrawGrid, DBGrid gb GroupBox iml ImageList img Image lbl Label, DBText, StaticText lbx ListBox, DBListBox lst List lvw ListView mmo Memo, DBMemo, RichEdit, DBRichEdit mit MenuItem mmn MainMenu nav DBNavigator nbk Notebook pbr ProgressBar pbx Paintbox pnl Panel qry Query rbt RadioButton rg RadioGroup rpt Report
O qualificador deverá descrever a finalidade do componente;
Exemplo:
btnFecharForm
- Repositório (JEDI)
Sempre que adicionar uma unit ao DPR lembre-se enviar para o repositório.
Só enviar para o servidor (CheckIn) conjunto de units que estejam, no mínimo, compiláveis.
JEDI: vídeo-aulas disponíveis em \\dataserver\Estudo\Video Aula JEDI.
- Transação
Ao testar o contexto da transção não utilizar “InTransaction”, usar “HasTransaction”, InTransaction verificar apenas se há um transação, HasTransaction já verifica se aquela transação realmente é a ultima empilhada.
Evite abrir muitas transações, torna-se o processo mais lento.
- Geral
Não deixar hints (acidentais) ou warnings pendentes. Em último caso, fazer uso de diretivas de compilação para torná-los sem efeito.
Só adicionar uma unit na seção uses, na plena certeza da sua necessidade. Quanto mais dependências existirem entre as units, menos chance de ser reaproveitada em outro módulo ou projeto haverá.
Não inclua códigos demorados na seção “Inicialization”, isso fará com que a aplicação pareça ser lenta logo na partida; Caso tenha alocados itens na seção “Inicialization” não esqueça de desalocar na seção “finalization”;
Fazer uso de constantes gerais e das classes de sistema, evitar deixar valores travados, dificulta a rastreio de manutenção