Delphi

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