Delphi

Siga a documentação https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Delphi%E2%80%99s_Object_Pascal_Style_Guide

Indentação

Dois espaços por nível

Não usar caracter de tabulação, desmarque "use tab character" e "optimal 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.

Exemplo:

 // incorreto
 for i:= 0 to 10 begin  

 // correto
 for i:= 0 to 10 do
   begin
     [..]
   end;

 if condicao then
   begin
     [..]
   end
 else 
   begin
     [..]
   end;

 while (not EOF) do
   begin
     [..]
   end;

Parênteses

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

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

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

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

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

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 é possível 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;

Exception Desnecessário: O exception original já traz a mensagem, ao realizar essa interceptação sem contribuição além de desnecessário perde as informações do exception original, como a classe do erro. Pois está criado um novo exception genérico apenas com a mensagem.

 except 
   on E: Exception do 
     raise Exception.create(E.Message);
 end;

Subtração de informação: Não omita o erro original, dificulta identificar o motivo real do erro

 except 
   on E: Exception do 
     raise Exception.create('Ocorreu uma falha ao incluir .... Contacte a Tek-System por favor.');
 end;

Troca da mensagem: Não há necessidade de criar um novo exception para completar a informação da mensagem

 except 
   on E: Exception do 
     raise Exception.create('Erro ao incluir o cliente: ' + E.Message);
 end;

Pode apenas atribuir mais informação a propriedade da mensagem e forçar o raise da mesma, assim mantem informações originais do exception, como exemplo a classe do erro.

 except 
   on E: Exception do
   begin 
     E.Message := 'Erro ao incluir o cliente: ' + E.Message;
     raise;
   end;
 end;

Sequência de execução: Ao executar o raise dentro do tratamento do exception irá abortar não executando o comando abaixo de Add na Stringlist

 except 
   on E: Exception do 
   begin
     raise;
     LogErro.Add('Erro ao carregar imagem ' + CDS.FieldByName('AUTOINC_ID_URL_IMAG').AsString + 13#13 + E.Message); 
   end;
 end;

O correto é o raise após o Add da stringlist

 except 
   on E: Exception do 
   begin
     LogErro.Add('Erro ao carregar imagem ' + CDS.FieldByName('AUTOINC_ID_URL_IMAG').AsString + 13#13 + E.Message); 
     raise;
   end;
 end;

Classes

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

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

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

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

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

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 transaçã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