0% acharam este documento útil (0 voto)
36 visualizações30 páginas

Intensive Delphi 2023

IntensiveDelphi2023

Enviado por

Welton Almeida
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
36 visualizações30 páginas

Intensive Delphi 2023

IntensiveDelphi2023

Enviado por

Welton Almeida
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
Você está na página 1/ 30

Style Guide – Padrões de

Código
Intensive Delphi 2023
Gabriel Baltazar
[email protected]
https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Delphi%E2%80%99s_Object_Pascal_Style_Guide
Que seu código já seja a documentação
Evite abreviações
Palavras chave minúsculas
Declaração de uses
Declaração de uses - EVITE
Linhas em branco – Onde usar?
• Entre declarações de classe.

• Entre as implementações do método.

• Às vezes, dentro de um método para separar


áreas lógicas de código, como antes de um loop.
Linhas em branco – Onde não usar?
• Declaração type.

• Separando a declaração do método do corpo

• Depois de outra linha em branco


Espaços em branco – Onde usar?
• Em torno de operadores.

• Após uma vírgula separando os parâmetros em uma chamada de função ou método.

• Após uma vírgula separando tipos genéricos.

• Após o ponto e vírgula na declaração dos parâmetros de uma função ou método.


Espaços em branco – Onde NÃO usar?
• Entre um nome de método e seu parêntese de abertura
• Após um parêntese de abertura ou antes de um parêntese de fechamento
• Após um colchete de abertura ou antes de um colchete de fechamento
• Antes dos dois pontos para uma declaração de variável; em outras palavras, nenhum espaço em branco
entre uma variável e o :
Espaços em branco – Onde NÃO usar?
Linhas de Continuação
Declarações – Variáveis Locais
As variáveis ​locais devem ter Camel Caps como todos os outros identificadores. Ao pensar em
convenções de nomenclatura, considere que nomes de campo de 1 caractere devem ser
evitados, exceto para variáveis ​temporárias e de loop. Em relação à nomenclatura de
variáveis ​locais, alguns desenvolvedores definem suas próprias regras como um L inicial, o que faz
sentido, mas não temos uma recomendação estrita para um prefixo de variáveis ​locais.
Declarações – Variáveis Locais
Embora você possa declarar vários identificadores do mesmo tipo em uma única linha, esse é um
estilo de codificação desencorajado (que também torna as diferenças de código de controle de
versão mais difíceis). Também é recomendável usar um único espaço após os dois pontos após o
nome da variável e evitar o alinhamento vertical dos nomes das variáveis.
Declarações – Variáveis Locais
Recomendamos o uso de variáveis inline para declarações de escopo local de bloco (ou seja, não
declare no método var variáveis ​de bloco que são usadas apenas em um bloco específico). Um
exemplo é uma variável local de loop for, que recomendamos declarar usando variáveis inline:
Declarações – if
As instruções if devem sempre aparecer em
pelo menos duas linhas. Não adicione
parênteses extras ao redor da condição
booleana de uma instrução if.

Em uma instrução if composta, coloque cada


instrução de separação de elemento (como
begin, else, end) em uma nova linha
separada. Ou seja, não coloque uma instrução
begin imediatamente após then.
Declarações – if
Algumas variações são consideradas válidas. Um deles usa uma instrução if na mesma
linha de uma condição else, mantendo a indentação original do bloco if externo
(enquanto formalmente este seria um bloco aninhado com indentação adicional).
Procedures e Functions

Se possível, uma declaração de função ou procedimento deve aparecer em uma linha. Se não
couber, as linhas pontilhadas serão alinhadas dois espaços à esquerda. Não é recomendado
colocar cada parâmetro em uma linha separada.
Parâmetros
Em relação à nomenclatura de parâmetros, alguns desenvolvedores definem suas próprias regras
como um A inicial, que significa “Argumento” e é frequentemente usado no código-fonte das
bibliotecas Delphi - mas não temos uma recomendação estrita para um prefixo de nome de
parâmetro.
Types
Como regra geral, todos os identificadores de nome de tipo são prefixados com um T maiúsculo,
como em TMyType .
Types - Exceções
• Classes de exceção (classe Exception e filhas) iniciam com letra E (EMyException).

• Os tipos de interface são prefixados com a letra maiúscula I (IMyInterface)

• Classes de atributos personalizados (descendentes de TCustomAttribute), não


usam a inicial T e devem terminar com a palavra Attribute (veremos adiante).
Types - Enumerados
Para os valores, foi recomendado usar as constantes com o nome do tipo de enumeração
como um prefixo. Por exemplo, os valores FontStyle começariam com fs e os valores
ButtonKind com bk . A razão reside no fato de que esses valores constantes são globais e um
prefixo ajuda a reduzir o risco de conflito de nomes. Exemplo:
Corpo da Classe
O corpo de uma declaração de classe deve ser organizado na seguinte ordem, para cada um
dos blocos:

• Fields
• Procedures e Functions
• Properties
Nomenclatura dos campos
Campos (Fields) começam cada declaração de tipo com F maiúsculo. Os Fields públicos tem o
F omitido.

Propriedades (property) não usam prefixos.


Property – Evite Get e Set desnecessário
Property – Evite Get e Set desnecessário
Embarcadero DocWiki

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Delphi%E2%80%99s_Object_Pascal_Style_Guide
Obrigado!

[email protected]

github.com/gabrielbaltazar

linkedin.com/in/gabrielbaltazar-dev/

Gabriel Baltazar

Você também pode gostar