1.Prefácio

Este documento tem como objetivo principal fornecer aos desenvolvedores Delphi um padrão de escrita de código-fonte, bem como um padrão de nomenclatura para programas e arquivos, para que possam ter um formato consistente a seguir durante a programação. Dessa forma, cada programador escreve um código que pode ser compreendido por outros.

2. Especificações de escrita do programa fonte

2.1. Regras gerais de formato de código-fonte

1).

Recuo significa dois espaços entre cada nível. Não coloque caracteres de tabulação no código-fonte. Isso ocorre porque a largura do caractere de tabulação varia com diferentes configurações e utilitários de gerenciamento de código (impressão, documentação, controle de versão, etc.).

Usando o menu Ferramentas | Ambiente, na página Geral da caixa de diálogo Opções de ambiente, desmarque as caixas de seleção Usar caractere de tabulação e Preenchimento opcional para que os caracteres de tabulação não sejam salvos.

2).

As margens são definidas para 80 caracteres. O código-fonte geralmente não excede a margem ao escrever uma palavra, mas esta regra é mais flexível. Sempre que possível, instruções com mais de uma linha devem ser colocadas entre vírgulas ou operadores. Após uma quebra de linha, ela deve ser recuada por dois caracteres.

3).instrução de início...fim

A instrução inicial deve estar sozinha em uma linha. Por exemplo, a primeira linha abaixo está incorreta, mas a segunda linha está correta:

for i:=0 to 10 do Begin // Errado, Begin e for estão na mesma linha

for i:=0 to 10 do // Sim, comece em outra linha

começar

Um caso especial desta regra é quando o início faz parte de uma instrução else, por exemplo:

se alguma afirmação = então

começar

.

fim

senão começar

Alguma outra declaração;

fim;

Nota: A instrução final está sempre em uma linha separada. Quando o início não faz parte de uma instrução else, a instrução final correspondente é recuada no mesmo valor que a instrução start.

4).Comentários

Geralmente usamos comentários de bloco do tipo "{...}". Os comentários de bloco do tipo "(*...*)" anteriores são usados ​​para comentar temporariamente o código não utilizado. A partir do Delphi 2, a linha "//" é suportada. comentários, se você decidir não suportar versões abaixo do Delphi 2.0, você pode usar o comentário "//".

2.2. Especificações e uso da escrita de instruções do formato de instrução Object Pascal.

1).

Não há espaço entre o colchete de abertura e o próximo caractere. Da mesma forma, não há espaço entre o colchete de fechamento e o caractere anterior. O exemplo a seguir demonstra espaços em branco corretos e incorretos.

CallPRoc( Parâmetro); // Erro!

CallProc(Aparâmetro); // Correto!

Não inclua parênteses extras nas declarações. No código-fonte, os parênteses são usados ​​apenas quando realmente necessários. Os exemplos a seguir demonstram o uso correto e incorreto:

if (I=42) then // Erro, os parênteses são redundantes

if (I=42) ou (J=42) then // Correto, colchetes devem ser usados

2). Palavras e palavras-chave reservadas

Palavras reservadas e palavras-chave na linguagem Object Pascal são sempre minúsculas. A seguir está uma lista de palavras reservadas do Delphi 5:

3). Procedimentos e funções

(1).

Os nomes dos procedimentos devem começar com uma letra maiúscula e ser escalonados para aumentar a legibilidade. O seguinte é uma forma incorreta de escrever:

procedimento este é um nome de rotina mal formatado;

Basta alterá-lo para isto:

procedimento ThisIsMuchMoreReadableRoutineName;

(2). Parâmetros formais.

(1) Formato

Sempre que possível, os parâmetros do mesmo tipo devem ser agrupados:

procedimento Foo(Param1,Param2,Param3:Imteger;Param4:string);

(2) Ordem dos parâmetros

A ordem dos parâmetros formais depende principalmente das regras de chamada de registradores. O parâmetro mais comumente utilizado deve ser o primeiro parâmetro, organizado da esquerda para a direita em ordem de frequência de uso. Os parâmetros de entrada precedem os parâmetros de saída. Parâmetros com intervalo grande devem ser colocados antes dos parâmetros com intervalo pequeno. Por exemplo:

SomeProc(aPlanet, aContinent, aCountry, aState, aCity).

Alguns são exceções. Por exemplo, durante o processamento de eventos, o parâmetro Sender do tipo TObject geralmente é o primeiro parâmetro a ser passado.

(3) Parâmetros constantes

Para evitar que parâmetros de registro, array, string curta ou tipo de interface sejam modificados pelo procedimento, o parâmetro formal deve ser marcado como Const. Desta forma, o compilador irá gerar o código da forma mais eficiente, garantindo que os parâmetros passados ​​sejam imutáveis.

Se não se espera que outros tipos de parâmetros sejam modificados pelo procedimento, eles também podem ser marcados como Const. Embora isso não tenha impacto na eficiência, fornece mais informações ao chamador do procedimento.

4).Variáveis

(1). Variáveis ​​locais.

Variáveis ​​locais são utilizadas dentro do procedimento. Se necessário, as variáveis ​​devem ser inicializadas imediatamente na entrada do procedimento. As variáveis ​​locais do tipo AnsiString são inicializadas automaticamente para uma string vazia, as variáveis ​​locais da interface e do tipo dispinterface são automaticamente inicializadas para nil e as variáveis ​​locais do tipo Variant e OleVariant são automaticamente inicializadas para Unassigned.

(2). Variáveis ​​globais.

O uso de variáveis ​​globais é geralmente desencorajado. No entanto, às vezes é necessário. Mesmo assim, as variáveis ​​globais devem ser restritas aos ambientes onde são necessárias. Por exemplo, uma variável global pode ser global apenas para a parte de implementação da unidade.

Os dados globais que serão usados ​​por muitas unidades devem ser movidos para uma unidade comum e usados ​​por todos os objetos. Os dados globais podem ser inicializados diretamente com um valor quando declarados. Observe que todas as variáveis ​​globais são automaticamente inicializadas com zero, portanto, não inicialize variáveis ​​globais com valores nulos, como 0, nil ou Unassigned. Variáveis ​​globais inicializadas com zero não ocupam espaço no arquivo .EXE. Os dados inicializados com zero são armazenados em um segmento de dados virtuais, e o segmento de dados virtuais aloca memória apenas quando o aplicativo é iniciado. Dados globais inicializados diferentes de zero ocupam espaço no arquivo .EXE.

5). Tipo

(1). Regras de capitalização.

Os identificadores de tipo são palavras reservadas e devem estar todos em letras minúsculas. Os tipos de API Win32 geralmente são todos em letras maiúsculas e seguem regras para nomes de tipos específicos, como Windows.pas ou outras unidades de API. Para outros nomes de variáveis, a primeira letra deve ser maiúscula e as demais letras devem ser alternadas. Aqui estão alguns exemplos:

var

MyString: string; // palavras reservadas

WindowsHandle: HWND; // Tipo de API Win32

I: Inteiro; //Identificador do tipo introduzido na unidade do sistema

(2).

O uso do tipo Real é desencorajado, pois é reservado apenas para compatibilidade com código Pascal mais antigo. Normalmente, Double deve ser usado para números de ponto flutuante. Double pode ser otimizado pelo processador e é um formato de dados padrão definido pelo IEEE. Extend pode ser usado quando um intervalo maior do que o Double fornece é necessário. Extend é um tipo específico da Intel e não é compatível com Java. Quando o número físico de bytes da variável de ponto flutuante for importante (talvez usando uma linguagem diferente para escrever a DLL), Single deverá ser usado.

(3).Variante e OleVariant

Geralmente não é recomendado usar Variant e OleVariant. Entretanto, esses dois tipos são necessários para programação quando o tipo de dados é conhecido apenas em tempo de execução (geralmente em aplicativos COM e de banco de dados). Ao fazer programação COM, como automatizar controles ActiveX, você deve usar OleVariant; para programação não COM, você deve usar Variant; Isso ocorre porque o Variant pode efetivamente salvar strings nativas do Delphi, enquanto o OleVariant converte todas as strings em strings OLE (ou seja, strings WideChar) e não possui função de contagem de referência.

6).

(1).Se declaração

Em uma instrução if/then/else, o caso de execução mais provável deve ser colocado na cláusula then, e o caso menos provável deve ser colocado na cláusula else. Para evitar muitas instruções if, use instruções case. Se houver mais de 5 níveis, não use instruções if. Use um método mais claro. Não use parênteses extras em instruções if.

Se houver múltiplas condições a serem testadas em uma instrução if, elas deverão ser ordenadas da direita para a esquerda em ordem de complexidade computacional. Isso permite que o código aproveite ao máximo a lógica de estimativa de curto-circuito do compilador. Por exemplo, se a Condição1 for mais rápida que a Condição2 e a Condição2 for mais rápida que a Condição3, a instrução if geralmente deve ser construída assim:

se Condição1 e Condição2 e Condição3 então

Se houver uma grande chance de que a Condição3 seja Falsa, usando a lógica de estimativa de curto-circuito, também podemos colocar a Condição3 na frente:

se Condição3 e Condição1 e Condição2 então

(2).

(1) Visão geral

As constantes para cada caso na instrução case devem ser organizadas em ordem numérica ou alfabética. A declaração de ação para cada situação deve ser curta e geralmente não mais que 4 a 5 linhas de código. Se a ação for muito complexa, o código deverá ser colocado em um procedimento ou função separada. A cláusula else da instrução Case é usada apenas para casos padrão ou detecção de erros.

(2) Formato

As instruções case seguem regras normais de indentação e nomenclatura.

(3).

Recomenda-se não usar o procedimento Exit para sair do loop while. Se necessário, uma condição de loop deve ser usada para sair do loop. Todo código que inicializa o loop while deve estar localizado antes da entrada while e não deve ser separado por instruções irrelevantes. Qualquer trabalho auxiliar ao negócio deverá ser realizado imediatamente após o ciclo.

(4).

Se o número de loops for determinado, uma instrução for deverá ser usada em vez de uma instrução while.

(5).repetir declaração

A instrução de repetição é semelhante a um loop while e segue as mesmas regras.

(6).

(1) Visão geral

A instrução with deve ser usada com cautela. Evite o uso excessivo de instruções with, especialmente ao usar vários objetos ou registros em uma instrução with. Por exemplo:

com Record1, Record2 faça

Essas situações podem facilmente confundir os programadores e dificultar a depuração.

(2) Formato

A instrução with também segue as regras deste capítulo para nomenclatura e recuo.

7). Tratamento estruturado de exceções

(1).

O tratamento de exceções é usado principalmente para corrigir erros e proteger recursos. Isso significa que onde quer que os recursos sejam alocados, try...finalmente deve ser usado para garantir que os recursos sejam liberados. Porém, exceções são feitas se os recursos forem alocados/liberados na parte inicial/final da unidade ou no construtor/destruidor do objeto.

(2). Uso de try...finalmente.

Sempre que possível, cada alocação de recurso deve corresponder a uma estrutura try...finalmente. Por exemplo, o código a seguir pode causar um erro:

SomeClass1 := TSomeClass.Create;

SomeClass2 := TSomeClass.Create;

tentar

{faça ​​algum código}

finalmente

SomeClass1.Free;

SomeClass2.Free;

fim;

Uma solução segura para a alocação de recursos acima é:

SomeClass1 := TSomeClass.Create;

tentar

SomeClass2 := TSomeClass.Create;

tentar

{faça ​​algum código}

finalmente

SomeClass2.Free;

fim;

finalmente

SomeClass1.Free;

fim;

(3). Uso de tentativa...exceto

Se você quiser executar alguma tarefa quando ocorrer uma exceção, você pode usar try...except. Normalmente, não há necessidade de usar try...exceto simplesmente para exibir uma mensagem de erro, porque o objeto do aplicativo pode fazer isso automaticamente com base no contexto. Se quiser ativar o tratamento de exceções padrão na cláusula, você poderá acionar a exceção novamente.

(4). Uso de try...except...else.

Usar try...except com uma cláusula else é desencorajado porque isso bloqueará todas as exceções, incluindo exceções que você não está preparado para tratar.

3. Convenção de nomenclatura

3.1. Procedimento e Função

1).Nome

Os nomes de procedimentos e funções devem ser significativos. É melhor prefixar o nome do processo de execução de uma ação com o verbo que expressa a ação. Por exemplo:

procedimento FormatHardDrive;

O nome do procedimento para definir os valores dos parâmetros de entrada deve ser prefixado com Set, por exemplo:

procedimento SetUserName;

O nome do procedimento para obtenção de um valor deve ser prefixado com Get, por exemplo:

função GetUserName:string;

2).Parâmetros formais

O nome de todos os parâmetros formais deve expressar a sua finalidade. Se apropriado, o nome do parâmetro formal é preferencialmente prefixado com a letra a, por exemplo:

procedimento SomeProc(aUserName:string; aUserAge:integer);

O prefixo a é necessário quando o nome do parâmetro tem o mesmo nome de um atributo ou campo de classe.

3).Conflito de nomenclatura

Quando duas unidades contêm procedimentos com o mesmo nome, se o procedimento for chamado, o procedimento na unidade que aparece posteriormente na cláusula Uses será realmente chamado. Para evitar isso, adicione o nome da unidade desejada antes do nome do método, por exemplo:

SysUtils.FindClose(SR);

ou Windows.FindClose(Handle);

3.2.

O nome de uma variável deve expressar sua finalidade. Variáveis ​​de controle de loop geralmente são letras únicas, como I, J ou K. Você também pode usar um nome mais significativo, como UserIndex. Os nomes das variáveis ​​booleanas devem indicar claramente o significado dos valores True e False.

1). Variáveis ​​locais

Variáveis ​​locais seguem as regras de nomenclatura de outras variáveis.

2). Variáveis ​​globais

As variáveis ​​globais começam com uma letra maiúscula “G” e seguem as regras de nomenclatura de outras variáveis.

3.3.Tipo

3.3.1.Tipos gerais

1). Tipo de enumeração

O nome do tipo de enumeração deve representar a finalidade da enumeração. O caractere T deve ser prefixado antes do nome para indicar que este é um tipo de dados. O prefixo da lista de identificadores do tipo enumeração deve conter de 2 a 3 caracteres minúsculos para associar entre si. Por exemplo:

TSongType=(stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);

O nome da instância da variável do tipo de enumeração é igual ao tipo, mas sem o prefixo T. Você também pode dar à variável um nome mais especial, como: FavoriteSongTypel, FavoriteSongType2, etc.

3.3.2.

1).Tipo de matriz

O nome do tipo de array deve expressar a finalidade do array. Os nomes dos tipos devem ser prefixados com a letra “T”. Se você deseja declarar um ponteiro para um tipo de array, você deve prefixá-lo com a letra P e declará-lo antes da declaração do tipo. Por exemplo:

tipo

PCycleArray = ^TCycleArray;

TCycleArray=array[1..100] de número inteiro;

Na verdade, uma instância variável de um tipo array tem o mesmo nome do tipo, mas sem o prefixo “T”.

2). Tipo de registro

O nome do tipo de registro deve expressar a finalidade do registro. Os nomes dos tipos devem ser prefixados com a letra T. Se quiser declarar um ponteiro para um tipo de registro, você deve prefixá-lo com a letra P e declará-lo antes da declaração do tipo. Por exemplo:

tipo

PEFuncionário = ^TEFuncionário;

TEFuncionário=registro

NomeDoFuncionário: string;

Taxa de Funcionário: Duplo;

fim;

3.3.3. Tipo de aula (Classe)

1).Nomenclatura e formato

O nome da aula deve expressar o propósito da aula. Geralmente, a letra "T" deve ser adicionada antes do nome da classe. Se for uma classe de interface, então "I" deve ser adicionado antes do nome da classe. O nome da classe de exceção de erro deve ser adicionado com "E". e o tipo de referência de classe (tipo de referência de classe) deve ser adicionado antes do nome da classe. Adicione "Classe" após o nome. Por exemplo:

tipo

TCliente = classe(TObject);

ICliente = interface;

TCustomerClass = classe de TCustomer

ECustomerException = classe(Exceção);

O nome da instância de uma classe geralmente é igual ao nome da classe, sem o prefixo "T".

var

Cliente: TCliente;

Nota: Para a nomenclatura dos componentes, consulte "Tipos de Componentes".

2).Campo

(1) Nomenclatura e formato

A nomenclatura dos campos segue as mesmas regras das variáveis, exceto que o prefixo F é adicionado para indicar que se trata de um campo.

(2) Visibilidade

Todos os campos devem ser privados. Se quiser acessar um campo fora do escopo de uma classe, você pode fazer isso com a ajuda dos atributos da classe.

3).Método

(1) Nomenclatura e formato

Os métodos de nomenclatura seguem as mesmas regras dos procedimentos e funções.

(2) Método estático

Métodos estáticos devem ser usados ​​quando você não deseja que um método seja substituído por classes derivadas.

(3) Método virtual (virtual) e método dinâmico (dinâmico)

Quando você deseja que um método seja substituído por classes derivadas, você deve usar métodos virtuais. Se um método de classe for usado direta ou indiretamente por múltiplas classes derivadas, métodos dinâmicos (dinâmicos) deverão ser usados. Por exemplo, se uma classe contiver um método frequentemente substituído e tiver 100 classes derivadas, o método deverá ser definido como dinâmico, o que pode reduzir a sobrecarga de memória.

(4) Método abstrato (resumo)

Se uma classe criar instâncias, não use métodos abstratos. Métodos abstratos só podem ser usados ​​em classes base que nunca criam instâncias.

(5) Método de acesso ao atributo

Todos os métodos de acesso à propriedade devem ser definidos na parte privada ou protegida da classe. Os métodos de acesso à propriedade seguem as mesmas regras dos procedimentos e funções. Os métodos utilizados para leitura devem ser prefixados com "Get", os métodos utilizados para escrita devem ser prefixados com "Set", e possuem um parâmetro chamado Value cujo tipo é igual ao tipo da propriedade. Por exemplo:

TSomeClass = classe(TObject)

privado

fsomeField: Inteiro;

protegido

função GetSomeField: Inteiro;

procedimento SetSomeField(Valor: Inteiro);

público

propriedade SomeField: Integer read GetSomeField write SetSomeField;

fim;

Embora não seja obrigatório, é recomendável usar métodos de acesso de gravação para acessar propriedades que representam campos privados.

4).Atributos

As propriedades servem como acessadoras para campos privados e seguem as mesmas regras de nomenclatura dos campos, exceto sem o prefixo F. Os nomes das propriedades devem ser substantivos, não verbos. Propriedades são dados e métodos são ações. Os nomes das propriedades da matriz devem ser plurais, enquanto as propriedades gerais devem ser singulares.

3.3.4.Tipo de componente

1). Padrões de nomenclatura para tipos de componentes.

A nomenclatura de componentes é semelhante à nomenclatura de classes, exceto que quando entrar em conflito com outros nomes de componentes, você poderá adicionar um prefixo de 3 caracteres para identificar uma empresa, indivíduo ou outra entidade. Por exemplo, um componente de relógio pode ser declarado assim:

TddgClock = classe(TComponent)

Observe que os três caracteres do prefixo devem estar em letras minúsculas.

2). Regras de nomenclatura para instâncias de componentes.

O nome da instância do componente deve ser capaz de descrever seu significado real. A convenção de nomenclatura aqui usa uma convenção de nomenclatura de prefixo húngaro modificada. A razão para usar um prefixo em vez de um sufixo é que é mais fácil pesquisar o nome do componente no Object Inspector e no Code Explorer do que pesquisar o tipo do componente. Neste padrão, o nome da instância do componente consiste em duas partes: o prefixo e o identificador do atributo.

(1). Prefixo do componente.

O prefixo de um componente é principalmente uma abreviatura do tipo de componente. Veja os prefixos dos componentes na tabela abaixo:

Conforme mostrado acima, o prefixo do tipo de componente vem da análise das propriedades de tipo que descrevem o componente. Normalmente, as regras a seguir descrevem como definir um prefixo de tipo de componente:

• Remova o prefixo T dos nomes dos tipos de componentes. Por exemplo, TButton se torna Button.
• Exclua todas as vogais, exceto a primeira vogal. Por exemplo, Button se torna bttn e Edit se torna edt.
• Letras duplas compactadas. Por exemplo, bttn torna-se btn.
• Em caso de conflito, uma vogal é adicionada a um dos prefixos componentes. Por exemplo, adicione uma vogal ao prefixo do componente TBatton e altere-a para batn para distinguir o prefixo de TButton.

• No entanto, as regras acima devem primeiro garantir que o nome do prefixo esteja em conformidade com o costume, para que o nome possa ser entendido. Por exemplo, o prefixo do controle TDDEClientConv é uma exceção.

Nota: O prefixo de um componente serve para indicar o tipo de componente, se é um botão, um rótulo, etc., portanto não há necessidade de criar um prefixo de componente para cada classe de componente especial. Por exemplo, o prefixo do componente de. TMyButton ainda está ligado.

(2). Nome de identificação da propriedade do componente.

O nome de identificação da propriedade do componente é uma descrição da intenção do componente. Por exemplo, uma instância do componente TButton usada para fechar um formulário poderia ser chamada de btnClose. Uma instância do componente de edição de nome pode ser denominada edName.

3.3.5. Tipos de formulário e diálogo.

1). Padrões de nomenclatura para tipos de formulário.

O nome do formulário ou tipo de diálogo deve expressar a finalidade do formulário, prefixado com "Tfrm" para um formulário ou "Tdlg" para uma caixa de diálogo, seguido de um nome descritivo. Por exemplo, o nome do tipo de formulário Sobre é:

TfrmSobre = classe(TForm)

O nome do tipo do formulário principal é:

TfrmPrincipal = classe(TForm)

O nome do tipo do formulário de login do cliente é:

TfrmCustomerEntry = classe(TForm)

O nome do tipo da caixa de diálogo de login é:

TdlgLogin = classe(TForm)

2). Padrões de nomenclatura para instâncias de formulário.

O nome da instância do formulário é igual ao nome do tipo correspondente, mas sem o prefixo T. Por exemplo, o nome do tipo de formulário e da instância mencionados anteriormente é:

3). Formulário criado automaticamente

A menos que haja motivos especiais, apenas o formulário principal é gerado automaticamente. Todos os outros formulários devem ser removidos da lista gerada automaticamente na caixa de diálogo Opções do Projeto. Para obter mais informações, consulte as seções a seguir.

4). Função de instanciação de formulário modal.

Todas as unidades de formulário devem conter funções de instanciação para criar, configurar, exibir modal e liberar o formulário. Esta função retornará o resultado do modo retornado pelo formulário. Os parâmetros passados ​​para esta função seguem as regras para passagem de parâmetros. A razão para um encapsulamento como esse é facilitar a reutilização e manutenção do código.

As variáveis ​​do formulário devem ser removidas da unidade e definidas como variáveis ​​locais na função de instanciação do formulário (observe que isso requer que o formulário seja removido da lista gerada automaticamente na caixa de diálogo Opções do Projeto. Consulte o conteúdo anterior.

Por exemplo, o arquivo de unidade a seguir demonstra a função de instanciação GetUserData.

Unidade UserDataFrm;

Interface

Usos

Windows, Mensagens, SysUtils, Classes, Gráficos, Controles, Formulários,

Diálogos, StdCtrls;

Tipo

TfrmUserData = classe(TForm)

edtUserName: TEdit;

edtUserID: TEdit;

privado

{Declarações privadas}

público

{Declarações públicas}

fim;

função GetUserData (var aUserName: String; var aUserID: Integer): Word;

implementação

{$R *.DFM}

função GetUserData (var aUserName: String; var aUserID: Integer): Word;

var

frmUserData: TfrmUserData;

começar

frmUserData := TfrmUserData.Create(Aplicativo);

frmUserData.Caption:='Obtendo dados do usuário';

Resultado: =frmUserData.ShowModal;

se Resultado=mrOK então

começar

aUserName := frmUserData.edtUserName.Text;

aUserID := StrToInt(frmUserData.edtUserID.Text);

fim;

finalmente

frmUserData.Free;

fim;

fim;

Fim.

5). Moldura de formulário e forma composta

Se uma estrutura de formulário for muito complexa, ela deverá ser dividida em um quadro de formulário principal e vários quadros de subformulário incorporados no quadro de formulário principal. como:

TfrmMainFrame: TfrmInfoFrame,TfrmEditorFrame

O principal objetivo do uso de frames de formulário é resolver o problema de reutilização de interface e código e melhorar a coesão do código unitário (após a divisão, cada frame de formulário é uma unidade independente), melhorando assim a qualidade da engenharia de software. Você deve extrair o código relacionado à interface (reutilizável) e o código relacionado ao aplicativo (não reutilizável).

3.3.6.Tipo de módulo de dados

1). Padrões de nomenclatura para módulos de dados.

O nome do tipo de módulo de dados deve expressar sua finalidade e ser prefixado com “Tdm” seguido de um nome descritivo. Por exemplo, o nome do tipo do módulo de dados do Cliente é:

TdmCustomer = classe(TDataModule)

O nome do tipo do módulo de dados Pedidos é:

TdmOrder = classe(TDataModule)

2). Padrões de nomenclatura para instâncias de módulos de dados.

O nome de uma instância do módulo de dados deve ser igual ao nome do tipo correspondente, mas sem o prefixo T. Por exemplo, o tipo de módulo de dados anterior e o nome da instância são os seguintes:

3.4.Documentos

Recomenda-se usar informações de cabeçalho de arquivo estruturado em todos os arquivos de origem, arquivos de projeto e arquivos de unidade. Um cabeçalho de arquivo deve conter pelo menos as seguintes informações:

{

Direitos autorais @ ano pelos autores

}

3.4.1.Arquivos de projeto

Os nomes dos arquivos do projeto devem ser descritivos. Por exemplo, o nome do projeto "The Delphi 5 Developer's Guide Bug Manager" é DDGBugs.dpr, e o nome de um programa de informações do sistema é SysInfo.dpr.

3.4.2. Arquivo de formulário

O nome do arquivo do formulário deve expressar a finalidade do formulário e ter o sufixo Frm. Por exemplo, o nome do arquivo do formulário Sobre é AboutFrm.dfm e o nome do arquivo do formulário principal é MainFrm.dfm.

3.4.3.Arquivos do módulo de dados

O nome do arquivo do módulo de dados deve expressar a função do módulo de dados e ter um sufixo DM. Por exemplo, o nome do arquivo do módulo de dados Clientes é CustomersDM.dfm.

3.4.4.Arquivo do módulo de dados remoto

O nome do arquivo do módulo de dados remoto deve expressar a finalidade do módulo de dados remoto. Adicione o sufixo RDM após o nome. Por exemplo, o arquivo do módulo de dados remotos Clientes é denominado CustomersRDM.dfm.

3.4.5.Arquivo de unidade

1). Unidade comum

(1) Nome da unidade

Os nomes das unidades devem ser descritivos. Por exemplo, a unidade de formulário principal do aplicativo é chamada MaimFrm.pas.

(2) Cláusula de usos

A cláusula Uses da seção Interface deve conter apenas as unidades exigidas por essa seção. Não inclua nomes de unidades que possam ser adicionados automaticamente pelo Delphi. A cláusula Uses da parte Implementação deve conter apenas as unidades necessárias para esta parte e nenhuma unidade extra.

(3) Parte da interface

A seção Interface deve conter apenas declarações de tipos, variáveis, procedimentos e funções que precisam ser acessados ​​por unidades externas. Além disso, estas declarações devem preceder a secção de Implementação.

(4) Parte de implementação

A parte de Implementação inclui a implementação de tipos, variáveis, procedimentos e funções privadas desta unidade.

(5) Parte de inicialização

Não coloque código demorado na seção Inicialização. Caso contrário, o aplicativo iniciará muito lentamente.

(6) Parte de finalização

Certifique-se de liberar todos os recursos alocados na seção Inicialização.

2).Unidade de formulário

O nome do arquivo da unidade de formulário é igual ao nome do formulário correspondente, basta alterar o prefixo para o sufixo. Por exemplo, o nome da unidade do formulário Sobre é AboutFrm.pas. O nome do arquivo da unidade do formulário principal é MainFrm.pas.

3).Unidade do módulo de dados

O nome do arquivo da unidade do módulo de dados é igual ao nome do módulo de dados correspondente. Por exemplo, o nome da unidade do módulo de dados é CustomersDM.pas.

4).Unidade geral

O nome de uma unidade geral deve expressar sua finalidade e ser prefixado com “u”. Por exemplo, o nome de uma unidade de ferramenta prática de depuração é uDebugUtilities.pas e o nome da unidade que contém variáveis ​​globais é uCustomerGlobals.pas.

Observe que os nomes das unidades devem ser exclusivos dentro de um projeto. Os nomes de unidades comuns não podem ter o mesmo nome.

5).Unidade componente

(1).

As células dos componentes devem ser colocadas em caminhos separados para indicar que são as células que definem o componente. Eles geralmente não são colocados no mesmo caminho do projeto. Os nomes dos arquivos das unidades devem expressar seu conteúdo.

Observe que consulte "Padrões de nomenclatura para tipos de componentes" para obter mais informações sobre padrões de nomenclatura de componentes.

Uma célula de componente pode conter apenas um componente primário, que é o componente que aparece na paleta de componentes. Outros componentes ou objetos auxiliares também podem ser incluídos na mesma unidade.

(2). Unidade de registro

O processo de registro de componentes deve ser retirado da unidade de componentes e colocado em uma unidade separada. Esta unidade de registro é usada para registrar todos os componentes, editores de propriedades, editores de componentes, assistentes, etc.

O registro do componente deverá ser feito no pacote de design. Portanto, a unidade de registro deve ser incluída no pacote de tempo de design e não no pacote de tempo de execução. Recomenda-se que a unidade de registro seja nomeada assim:

xxxReg.pas

Entre eles, o prefixo de caracteres xxx é usado para identificar o nome do pacote de componentes ou empresa, indivíduo ou outra entidade. Por exemplo, a unidade de registro é denominada xxxReg.pas.

6). Regras de nomenclatura de arquivo de pacote (.dpk).

(1). Pacote de tempo de execução e pacote de design.

O pacote de tempo de execução deve conter apenas as unidades necessárias. Esses elementos do editor de propriedades e do editor de componentes devem ser colocados no pacote de tempo de design. As unidades de registo também devem ser incluídas no pacote da fase de concepção.

(2). Padrões de nomenclatura de arquivos.

A nomenclatura dos pacotes segue o seguinte padrão:

dcliiiDescvvCn.pkg —Pacote de design

iiiDescvvCn.pkg —pacote de tempo de execução

Entre eles, iii representa um prefixo de 2 a 3 caracteres, que é usado para identificar empresas, indivíduos ou outras coisas que precisam ser identificadas. Desc representa uma breve descrição do pacote de controle; pacote. Você pode escolher de acordo com suas necessidades; O prefixo "dcl" indica um pacote de tempo de design, sem este prefixo indica um pacote de tempo de execução; Delphi5=D5, Delphi4=D4, CBuilder3=C3....

Observe que lib ou std no nome do pacote indica se este é um pacote em tempo de design ou um pacote em tempo de execução, respectivamente. Por exemplo:

dclrbStdComPSD5.pkg —Pacote de tempo de design Delphi 5

rbStdCompsD5.pkg —Pacote de tempo de execução Delphi 5

4. Ferramenta de formatação automática de código Delphi

Embora a maioria das ferramentas de formatação automática de código possa ajudá-lo a reorganizar o formato do programa de origem e atualizar a capitalização de palavras reservadas e identificadores, é melhor fazer isso antes de usar o controle de versão. Se você já usou o controle de versão, é recomendável não fazer isso. Não use facilmente ferramentas de formatação automática de código. Mesmo que haja mais um espaço, a ferramenta de controle de versão pensará que a linha foi modificada, causando alterações no gerenciamento do programa.