Guia de estilo Object Pascal - Por Charles Calvert
(Guia de estilo de codificação Object Pascal - Traduzido por: Tommy Tong)
Reconhecemos que muitos estúdios ou indivíduos bem estabelecidos têm suas próprias práticas de programação que diferem daquelas descritas neste artigo, no entanto, recomendamos fortemente que você use uma ferramenta para converter seu código em código estilo Borland e, em seguida, envie-o para a Borland, PRoject JEDI ou qualquer outro repositório de código-fonte público. Não queremos forçá-lo a mudar seus hábitos, mas insistimos que todo código que funcione com os produtos Borland siga os hábitos descritos neste artigo.
Object Pascal é uma bela linguagem de design. A forte legibilidade é uma de suas vantagens. Os padrões desenvolvidos neste artigo irão aprimorar a legibilidade do código Object Pascal. Quando os desenvolvedores seguirem esses hábitos simples demonstrados neste artigo, eles também se tornarão padrões, o que beneficiará todos os desenvolvedores Delphi que usam um estilo de codificação unificado e legível. Os esforços para fazer cumprir esses padrões aumentarão o valor do código-fonte para os desenvolvedores, especialmente durante as fases do ciclo de manutenção e depuração.
Embora acreditemos e admiremos o estilo promovido neste artigo, não o endossamos necessariamente porque é certo em si mesmo e errado nos outros. Porém, acreditamos que o padrão seguido pela grande maioria dos desenvolvedores tem sua validade, por isso ainda apoiamos e mantemos esse estilo. O cérebro humano está sempre se adaptando aos padrões e encontrando maneiras de organizar rapidamente padrões familiares para que seu significado possa ser compreendido de forma rápida e eficiente. É esse requisito que estabelece padrões que facilitarão ao máximo a leitura do código por um grande número de pessoas. Se as nossas diretrizes lhe parecerem desconhecidas pela primeira vez, então pedimos que você as siga por um tempo e você descobrirá que se acostumará com elas. Ou, se preferir, você pode manter seu próprio estilo e convertê-lo através de um programa que atenda aos nossos padrões, e então enviar seu código para a Borland ou outros repositórios.
Alguns editores de texto, como o Visual SlickEdit, podem ajudá-lo a formatar seu código em um determinado estilo.
Um formatador gratuito desenvolvido por Egbert van Nes está disponível em:
http://www.slm.wau.nl/wkao/delforexp.html
Outro programa comercial para Delphi é o CrackerJax:
http://www.kineticsoftware.com/html/products.html
-------------------------------------------------- ----
1.0 Introdução
Este artigo não é uma tentativa de definir regras de sintaxe para a linguagem Object Pascal. Por exemplo: é ilegal colocar o selo ";" antes de else; Portanto, não mostrarei as regras gramaticais neste artigo. Este artigo tem como objetivo definir o comportamento apropriado onde a linguagem oferece escolhas. Normalmente fico em silêncio onde existe apenas um método de controle.
1.1 Antecedentes
As diretrizes apresentadas neste artigo são baseadas em parte do código-fonte do Delphi. O código-fonte do Delphi segue exatamente essas diretrizes. Se você encontrar uma violação desses princípios, então esses princípios, e não o código-fonte incerto, devem ser sua diretriz. No entanto, você pode usar o código original como um complemento a esses princípios, pelo menos para ajudá-lo a ter uma ideia geral da forma do seu próprio código.
1.2 Obrigado
Os formatos neste artigo baseiam-se no trabalho realizado para definir padrões de estilo para a linguagem Java. Java não tem influência nas regras de formatação do código-fonte Object Pascal, mas a documentação no site da Sun é a base deste artigo. Em alguns lugares especiais, o estilo e formato deste artigo foram grandemente inspirados em "A Coding Style Guide for Java WorkShop and Java Studio Programming" (Achut Reddy, "Coding Guide for Java WorkShop and Java Studio"). O artigo pode ser encontrado neste URL: http://www.sun.com/workshop/java/wp-coding
A equipe Delphi deu uma contribuição significativa para a conclusão deste artigo. Na verdade, sem a ajuda deles, este artigo não teria sido concluído.
2.0 Arquivos de origem
O código-fonte do Object Pascal é dividido principalmente em arquivos de origem únicos e arquivos de projeto, e todos seguem a mesma convenção. Os arquivos de projeto Delphi possuem uma extensão .DPR. É o arquivo principal do projeto. Qualquer arquivo de unidade usado em um projeto possui uma extensão .PAS. Outros arquivos, como arquivos em lote, arquivos HTML ou DLLs, também podem desempenhar uma função no projeto, mas este artigo cobre apenas arquivos de projeto e arquivos de unidade.
2.1 Nomenclatura do arquivo fonte
Object Pascal suporta nomes de arquivos longos. Se você estiver usando várias palavras para formar um único nome, é melhor usar uma letra inicial maiúscula para cada palavra: MeuArquivo.pas. Isso é considerado parêntese ou camelCase. As extensões devem estar em letras minúsculas. Por razões históricas, o código-fonte Delphi geralmente usa o padrão de nomenclatura 8:3, mas os desenvolvedores não precisam se restringir às regras acima e recorrer ao uso da equipe Delphi.
Se você estiver traduzindo um arquivo de cabeçalho C/C++, o arquivo Pascal que você traduzirá deverá manter o mesmo nome de arquivo principal do arquivo de cabeçalho C/C++ e usar .PAS como extensão. Por exemplo: Windows.h -> Windows.pas. Se a sintaxe Pascal forçar você a combinar vários arquivos de cabeçalho em um único arquivo de unidade, então o nome do arquivo de cabeçalho que contém os outros arquivos de cabeçalho será usado como o nome do novo arquivo de unidade. Por exemplo: Windows.h contém o arquivo WinBase.h, então o novo arquivo de unidade é denominado Windows.pas.
2.2 Organização do arquivo fonte
Todos os arquivos de unidade Object Pascal devem conter os seguintes elementos na seguinte ordem:
Comentários sobre direitos autorais/bloqueio de identidade
nome da unidade
segmento de interface
Parte de implementação
Um terminador "fim".
Deve haver pelo menos uma linha vazia entre cada seção.
Outros elementos devem ser estruturados na ordem que você achar mais apropriada. Mas os direitos autorais devem aparecer bem no início do arquivo, depois o nome da unidade, depois quaisquer definições condicionais, diretivas do compilador ou instruções de inclusão e, em seguida, a cláusula de uso:
{************************************************ * *****}
{ }
{Biblioteca de componentes visuais Borland Delphi}
{ }
{Direitos autorais (c) 1995,98 Inprise Corporation}
{ }
{************************************************ * *****}
unidade Botões;
{$S-,W-,R-}
{$C PRÉ-CARGA}
interface
usa
Janelas, Mensagens, Aulas,
Controles, Formulários, Gráficos,
StdCtrls, ExtCtrls, CommCtrl;
Se você colocar a seção type antes da seção const ou misturar as duas, não terá efeito.
A parte de implementação precisa escrever primeiro a implementação, depois a cláusula de uso e depois incluir declarações ou outros indicadores:
implementação
usa
Consts, SysUtils, ActnList,
ListaImg;
{$R BOTÕES.RES}
2.2.1 Comentários sobre bloqueio de direitos autorais/identidade
Todo arquivo fonte deve começar com um comentário em bloco contendo informações sobre a versão e um aviso padrão de direitos autorais. As informações da versão podem ser assim:
{************************************************ * *****}
{ }
{Widgets em abundância}
{ }
{ Copyright (c) 1995,98 Sua Empresa }
{ }
{************************************************ * *****}
O aviso de direitos autorais deve conter pelo menos as seguintes linhas:
Copyright (C) Ano Proprietário dos direitos autorais
Se você for um terceiro desenvolvedor de software para a Borland, poderá adicionar seu próprio nome no final dos direitos autorais:
{************************************************ * *****}
{ }
{Biblioteca de componentes visuais Borland Delphi}
{ Copyright (c) 1995,99 Borland International }
{Criado pelo Projeto JEDI}
{ }
{************************************************ * *****}
2.2.2 declaração de unidade
Cada arquivo de unidade deve ter uma declaração de unidade. unit é uma palavra reservada, portanto precisa estar em minúsculas. O nome da unidade pode ser misto, mas deve ser igual ao nome do arquivo da unidade. Por exemplo:
unidade MinhaUnidade;
Então o nome do arquivo da unidade deve ser MyUnit.pas. No sistema de arquivos, ele serve como entrada para este arquivo.
2.2.3 declaração de uso
Dentro de uma unidade, as declarações de uso devem ser inicializadas com usos menores. O nome da unidade referenciada segue a convenção de letras maiúsculas usada quando é definido em sua própria unidade:
usaMinhaUnit;
Cada nome de unidade é separado do nome da unidade adjacente por uma vírgula e o último nome da unidade é seguido por ponto e vírgula:
usa
Windows, SysUtils, Classes, Gráficos, Controles, Formulários,
TipoInfo;
Também é correto adicionar o nome da unidade a partir da próxima linha de usos e adicionar o nome da unidade diretamente após os usos.
usa Windows, SysUtils, Classes, Gráficos, Controles, Formulários,
TipoInfo;
Você pode formatar sua lista de nomes de unidades para dentro do limite de 80 caracteres ou para ter uma linha por nome de unidade.
2.2.4 Definições de classe e interface
As definições de classe começam com dois espaços, seguidos por um prefixo “T”. O prefixo deve ser maiúsculo e cada palavra incorporada deve começar com maiúscula. Não use o caractere de tabulação "Tab" no código-fonte do Object Pascal. exemplo:
TMyClass
Segue o identificador com um espaço, depois um sinal de igual e depois a palavra classe, que deve estar em minúscula:
TMyClass = turma
Se sua classe herda de um ancestral, você precisa adicionar colchetes esquerdo e direito contendo a classe ancestral:
TMyClass = classe(TObject)
Os indicadores de intervalo estão a dois espaços da margem e aparecem na seguinte ordem:
TMyClass = clss(TObject)
privado
proteger
público
publicado
fim;
Os dados geralmente são declarados apenas na seção privada e seus identificadores começam com “F”. Todas essas declarações devem estar a 4 espaços da margem:
TMyClass = classe (TObject)
privado
FMyDate: Inteiro;
função GetDate: Inteiro;
procedimento SetData(Valor: Inteiro);
público
publicado
propriedade MyData: leitura inteira GetData gravação SetData;
fim ;
As interfaces seguem as mesmas regras que suas contrapartes, exceto que você deve ignorar os indicadores de escopo e os dados privados e usar a palavra interface em vez da palavra classe.
convenção de nomenclatura
Exceto para palavras reservadas e indicadores, que são minúsculos, todos os identificadores Pascal devem usar o formato camelCase, ou seja, a primeira letra de cada identificador deve ser maiúscula, e a primeira letra das palavras incorporadas também deve ser maiúscula. que leva apenas a primeira letra.
Meu identificador
Minha classe FTP
A principal exceção a esta regra é o caso de traduções de arquivos de cabeçalho, que devem seguir as convenções de nomenclatura dos arquivos de cabeçalho originais. Por exemplo:
WM_LBUTTONDOWN, não escreva wm_LButtonDown.
Exceto para traduções de arquivos de cabeçalho, não use sublinhados para separar palavras. Os nomes das classes devem ser substantivos ou sintagmas nominais. O nome da interface ou classe depende do propósito óbvio e do uso da interface.
Bom nome:
AddressForm, ArrayIndexOutOfBoundsException
Nomes ruins:
ManageLayout //Usar frase verbal
delphi_is_new_to_me //Usar sublinhado
3.1 Nomenclatura de unidades
Veja a declaração da unidade
3.2 Nomenclatura de classe/interface
Veja a declaração de classe/interface
3.3 Nomenclatura de domínio/campo
Use o formato camelCase. Comece com "F" maiúsculo e declare todos os dados como privados, usando propriedades ou getters e setters para fornecer acesso público. Por exemplo: use o nome GetSomething para nomear uma função que retorna um campo/valor de campo interno e use SetSomething para nomear um procedimento que defina um campo/valor de campo.
Não use todas as letras maiúsculas nas seções const, a menos que seja necessário para a tradução do arquivo de cabeçalho.
O Delphi foi desenvolvido na Califórnia, por isso desencorajamos o uso de tokens, a menos que seja necessário para a tradução do arquivo de cabeçalho.
correto:
FMyString: string;
Incorreto:
lpstrMyString: string;
É claro que a nomenclatura húngara é preservada na definição do tipo de enumeração:
TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkSim, bkNão, bkClose, bkAbort, bkRetry,
bkignore, bkTodos);
Neste caso o caracter bk é inserido antes de cada elemento deste tipo de enumeração. bk significa ButtonKind.
Ao considerar convenções de nomenclatura, evite usar nomes com um único caractere, exceto para variáveis de tempo zero e variáveis de loop.
Evite usar a variável "l" (L) porque é difícil distinguir de "1" (um) em uma impressora ou monitor.
3.4 Nomeação de métodos
A nomenclatura de métodos também usa o formato camelCase. As convenções de nomenclatura de métodos são iguais à nomenclatura de campos não const, mas podem ser diferenciadas do contexto. A nomeação de métodos deve impor o uso de verbos ou frases verbais. Por exemplo:
//Boa nomenclatura de métodos:
ShowStatus, DrawCircle, AddLayoutComponent
//Nomeação incorreta do método:
MouseButton //frase nominal, sem função de descrição
drawCircle //Começa com letra minúscula
add_layout_component //O sublinhado é usado
//As funções dos métodos a seguir não são suficientemente claras. Ele inicia a execução de um serviço (melhor: StartServer) ou determina se um serviço está em execução (melhor: IsServerRunning)?
ServerRunning //Frase verbal, mas não um comando
Um método para obter ou definir algumas propriedades de classe deve ser chamado GetProperty ou SetProperty respectivamente, onde Property representa o nome da propriedade. Por exemplo:
ObterAltura, DefinirAltura
Um método que testa uma propriedade booleana de uma classe deve ser denominado IsVisible, onde Visible representa o nome da propriedade. Por exemplo:
É redimensionável, é visível
3.5 Nomeando variáveis locais
As regras de nomenclatura para variáveis locais são as mesmas dos campos/campos, exceto que "F" não é usado. Consulte a seção 3.3.
3.6 Palavras reservadas
Palavras reservadas e indicadores devem estar em letras minúsculas. Isso pode ser um pouco confuso às vezes. Por exemplo: Inteiro é um identificador e aparece com a primeira letra maiúscula. As palavras reservadas da string estão todas em letras minúsculas.
3.7 Declaração de tipo
Todas as declarações de nome de tipo começam com a letra T e seguem o mesmo nome da classe.
4.0 Uso de espaço em branco
4.1 Linhas em branco
As linhas em branco podem melhorar a legibilidade agrupando segmentos de código relacionados logicamente. Uma linha em branco também pode ser usada nos seguintes locais:
Após o bloco de comentários de direitos autorais, a declaração do pacote (pacote) e a seção de importação (importação).
entre declarações de classe.
entre declarações de método.
4.2 Espaços
Object Pascal é uma linguagem muito clara e legível. Normalmente, você não precisa adicionar muitos espaços para separar linhas em seu código. Os artigos a seguir fornecem algumas diretrizes para o uso de espaços em branco:
4.2.2 Não devem ser utilizados espaços:
Entre o nome do método e o colchete de abertura;
Antes ou depois do operador .(ponto);
entre um operador unário e seu operando;
Entre um tipo e a expressão que ele lança;
depois do colchete esquerdo e antes do colchete direito;
depois do colchete esquerdo e antes do colchete direito;
antes de uma proibição;
Por exemplo:
//Uso correto:
função TMyClass.MyFunc(var Valor: Inteiro);
MeuPonteiro := @MeuRecord;
MinhaClasse := TMyClass(MeuPonteiro);
MeuInteger := MeuIntegerArray[5];
//Uso incorreto:
função TMyClass.MyFunc(var Valor: Inteiro);
MeuPonteiro := @MeuRecord;
MinhaClasse := TMyClass(MeuPonteiro);
MeuInteger := MeuIntegerArray[5];
4.3 Recuo
Você deve sempre recuar todos os níveis de recuo com dois espaços. Em outras palavras, o primeiro nível é recuado por dois espaços, o segundo nível é recuado por quatro espaços, o terceiro nível é recuado por seis espaços... Não use o caractere de tabulação Tab.
Claro, ainda existem algumas exceções. Palavras reservadas como unidade, usos, tipo, interface, implementação, inicialização e finalização estão sempre em maiúsculas. O último identificador final da célula também é de nível superior. No arquivo do projeto, o programa e o início e fim principais também estão na grade superior. O bloco inicial principal..fim precisa ser recuado em pelo menos dois espaços.
4.4 Continuação
As linhas devem ser limitadas a 80 colunas. Linhas com mais de 80 colunas devem ser divididas em múltiplas linhas consecutivas. Todas as linhas subsequentes devem seguir a primeira linha desta declaração e ser recuadas por dois caracteres de espaço.
Por exemplo:
//correto:
função CreateWindowEx(dwExStyle: DWord;
lpClassName: PChar; lpWindowName: PChar;
dwStyle: DWORD;
hWndParent: HWND hMenu: HMENU;
lpParam: Ponteiro): HWND ;
se ((X = Y) ou (Y = X) ou
(Z = P) ou (F = J) então
começar
S:= J;
fim ;
Não envolva linhas entre um parâmetro e seu tipo, a menos que a lista seja separada por vírgulas; nesse caso, envolva antes do último parâmetro para que o nome do tipo comece na próxima linha. Não deve haver espaço entre os dois pontos e sua variável, e deve haver um espaço entre os dois pontos e o nome do tipo.
//correto:
procedimento Foo(Param1: Inteiro; Param2: Inteiro);
//erro:
procedimento Foo(Param:Inteiro; Param2:Inteiro);
Uma linha subsequente não deve começar com um operador binário. Evite cortar uma linha onde normalmente não ocorrem espaços em branco, como entre o nome de um método e seu colchete de abertura ou entre o nome de um array e seu colchete de abertura. Se você precisar quebrar linhas na situação acima, quebre a linha após o colchete de abertura ou colchete de abertura. Não coloque start na mesma linha de outro código.
Por exemplo:
//erro:
while (LongExpression1 ou LongExpression2 ) começa
//FaçaAlguma Coisa
//DoSomethingElse;
fim ;
//correto
enquanto (LongExpression1 ou longExpression2) faça
começar
//FaçaAlguma Coisa
//DoSomethingElse;
fim ;
se (LongExpressiong1) ou
(LongExpressão2) ou
(LongExpressão3) então
5.0 Comentários
A linguagem Object Pascal suporta dois tipos de comentários: comentários em bloco e comentários de linha única. Aqui estão algumas diretrizes de uso de anotações:
·É útil colocar comentários no topo da unidade explicando o propósito da unidade
·É útil colocar comentários antes das declarações da classe
·É útil definir anotações antes das declarações de métodos
·Evite comentários com significados óbvios
i := i + 1; //Adiciona um a i
·Lembre-se de que comentários facilmente mal interpretados são mais prejudiciais do que nenhum comentário.
·Evite colocar informações nos comentários que pareçam inválidas
·Evite incorporar asteriscos ou outros símbolos tipográficos nas bordas dos comentários
·Comentários de hora zero, ou seja, comentários que precisam ser alterados ou excluídos, devem ser marcados com "???:" antes deles, para que sejam fáceis de encontrar. Conceitualmente, todos os comentários de tempo zero devem ser excluídos antes do lançamento do programa.
// ???: Altere para chamar Sort quando for corrigido
List.MySort;
5.1 Bloquear comentários
Object Pascal suporta dois tipos de comentários em bloco. Os mais comumente usados são comentários entre chaves {}. A equipe Delphi manteve os comentários tão poucos e simples quanto possível. Por exemplo: você deve evitar usar asteriscos para criar padrões ou linhas em seus comentários. Em vez disso, use espaços para separar seus comentários, como faria em um documento de processamento de texto. As palavras em seu comentário devem começar na mesma linha da primeira chave, como no seguinte trecho de DsgnIntf.pas:
{ TPropertyEditor
Edita uma propriedade de um componente ou lista de componentes.
selecionado no Inspetor de objetos A propriedade.
editor é criado com base no tipo do
propriedade sendo editada conforme determinado pelos tipos
registrado por...
etc...
ObterXxxValor
Obtém o valor da primeira propriedade no
Propriedades Chama a propriedade apropriada.
Método TProperty GetXxxValue para recuperar o
valor.
SetXxxValue Define o valor de todas as propriedades
na propriedade Properties Chama o apropriado.
Métodos TProperty SetXxxxValue para definir o valor }.
Comentários em bloco são frequentemente usados em comentários de direitos autorais. Também usado para comentar algumas linhas de código.
Um comentário em bloco explicando o propósito do método deve ser precedido pela declaração do método.
Por exemplo:
// CORRETO
{TMyObject.MeuMetodo
Esta rotina permite executar código.
procedimento TMyObject.MyMethod;
começar
fim;
//INCORRETO
procedimento TMyObject.MyMethod;
{********************************************** ****
TMyObject.MeuMetodo
Esta rotina permite executar código.
************************************************** * *****}
começar
fim;
O segundo tipo de comentário em bloco contém dois caracteres, parênteses e um asterisco: (* *). Isso às vezes é chamado de comentário entre colchetes. Essas anotações geralmente são úteis apenas durante o desenvolvimento do código e seu principal benefício é que permitem que as anotações aninhadas tenham menos de dois níveis de profundidade. O Object Pascal não suporta o mesmo tipo de aninhamento de comentários, portanto, há realmente apenas um nível de aninhamento: chaves dentro de chaves em estrela ou chaves em estrela dentro de chaves. Anotações Pascal padrão de outros tipos dentro de anotações deste tipo serão ignoradas desde que você não as aninhe. Portanto, você pode usar esta sintaxe para comentar um grande bloco de código que contém código e comentários:
(* procedimento TForm1.Button1Click(Sender: TObject);
começar
FaçaIsso; // Inicia o processo
DoThat; // Continua a iteração
{ Precisamos de uma maneira de relatar erros aqui, talvez usando
uma tentativa finalmente bloquear ???
CallMoreCode; // Finaliza o processo
fim ; *)
Nesse caso, todo o método Button1Click é comentado, incluindo quaisquer subcomentários dentro dele.
5.2 Comentários de linha única
Um comentário de linha única consiste em um caractere de comentário // e seu texto inicial, com um espaço entre o texto e o caractere de comentário. Se os comentários de linha única estiverem em linhas diferentes do código, eles deverão ter o mesmo nível de recuo do código. Você pode usar vários comentários de linha única para formar um comentário grande.
É necessária uma linha em branco antes de um comentário de linha única ou grupo de comentários, a menos que seja a primeira linha de um bloco. Se os comentários forem usados para diversas declarações, os comentários e grupos de comentários deverão ser seguidos por uma linha em branco. Se o comentário apenas explica a afirmação na linha seguinte, não precisa ser seguido de uma linha em branco.
Por exemplo:
//Abre o banco de dados
Tabela1.Abrir;
Comentários de linha única também podem seguir as declarações de código que explicam. Esses comentários são às vezes chamados de comentários de rastreamento. Deve haver pelo menos um espaço entre eles e o código. Se vários comentários de rastreamento aparecerem simultaneamente em um bloco de código, esses comentários precisarão ser alinhados.
Por exemplo:
se ( não é visível) então
Sair; // nada para fazer
Inc(StrLength); // reserva espaço para terminador nulo
Evite rastrear comentários em cada linha do código executável. Geralmente é melhor limitar o uso de comentários, ou mesmo deixá-los vazios, entre os blocos inicial e final de um método ou função. Comentários longos podem aparecer em comentários em bloco antes da definição de métodos e funções.
tipo
6.1 Organização das aulas
A organização dos órgãos de classe deverá seguir a seguinte ordem:
·Declaração de domínio/campo
·Declaração de método
·Definição de atributos
Domínios/campos, propriedades e métodos devem ser indexados alfabeticamente por seus nomes.
6.1.1 Níveis de acesso
Exceto para o código gerado pelo IDE, os designadores de escopo das classes devem estar na seguinte ordem:
·declaração privada
·declaração de proteção
· declaração pública
·Declaração publicada
No Object Pascal, os membros da classe têm quatro níveis de acesso: publicado, público, protegido e privado – em ordem decrescente de capacidade de acesso. O nível de acesso padrão é publicado. Geralmente, um membro deve receber o nível de acesso mais baixo que seja mais apropriado para ele. Por exemplo: membros que só podem ser acessados por outras classes da mesma unidade devem ser declarados privados. Ao mesmo tempo, declarar membros com baixos níveis de acesso também dá ao compilador a oportunidade de melhorar a otimização. É claro que, por outro lado, o uso de baixos níveis de acesso dificulta a extensão das subclasses. Se houver razão para acreditar que uma classe será subclassificada em algum momento no futuro, então os membros que precisam ser herdados e estendidos pela subclasse deverão ser declarados como propriedades protegidas usadas para acessar dados privados também podem fornecer essa proteção.
Você deve proibir o acesso público aos dados. Os dados geralmente são declarados na seção privada, e qualquer acesso público a eles deve ser feito através dos métodos ou propriedades GetXXX, SetXXX.
6.1.8 Declaração do construtor
Os métodos precisam ser classificados por índice alfabético. É correto colocar os construtores e destruidores no início da seção pública ou organizá-los em ordem alfabética.
Se houver vários construtores ou você usar vários construtores com o mesmo nome, eles deverão ser organizados de acordo com a lista de parâmetros, com aquele com menos parâmetros na frente daquele com mais parâmetros. Isso significa que se houver um construtor sem parâmetros, ele deverá aparecer primeiro. Para manter a melhor compatibilidade com o C++Builder, a lista de parâmetros do construtor deve ser exclusiva. C++ não chama um construtor com base em seu nome; portanto, a única maneira de distinguir vários construtores é por meio de sua lista de argumentos.
6.2 Declaração de método
Se possível, as declarações dos métodos devem aparecer em uma única linha.
Por exemplo:
Exemplos:
procedimento ImageUpdate (imagem img, infoflags: inteiro,
x: Inteiro, y: Inteiro, w: Inteiro, h: Inteiro)
Interface 7.0
Uma declaração de interface tem o mesmo formato que uma declaração de classe:
InterfaceName = interface ([ interface herdada ])
InterfaceBody
fim ;
As declarações de interface devem ser recuadas com dois espaços, os corpos da interface com quatro espaços e os caracteres finais com dois espaços.
Não há campos/campos na declaração da interface. Mas atributos podem aparecer.
Todos os métodos de interface são inerentemente públicos e abstratos e não há necessidade de incluir tais palavras-chave na declaração da interface.
Salvo indicação em contrário, as declarações de interface têm o mesmo estilo que as declarações do mesmo tipo.
7.1 Organização do corpo de interface
O corpo da interface pode ser organizado na seguinte ordem:
·Declaração de método de interface
·Declaração de atributos de interface
Os métodos e propriedades da interface são declarados no mesmo estilo das classes.
Declaração 8.0
Uma declaração é uma linha ou linhas de código que terminam com um selo. Uma única declaração possui apenas um número de banimento e uma declaração composta possui vários nomes de banimento.
//Esta é uma declaração única:
UMA:= B;
//Esta é uma instrução composta:
começar
B:= C;
UMA:= B;
fim ;
8.0.1 Declaração única
Se uma única instrução precisar ser quebrada, ela precisará ser recuada com dois espaços em relação à linha anterior.
//Por exemplo:
MeuValor :=
MeuValor + (SomeVeryLongStatement / OtherLongStatement);
8.1.1 Declarações de atribuição e expressão
Pode haver no máximo uma instrução por linha.
Por exemplo:
a := b + c;
a := b + c; //Correto
Inc(Contagem); //Correto
8.1.2 Declaração de variável local
Variáveis locais também usam o formato camelCase. Não use o líder "F", que é reservado para campos/campos em declarações de classe.
Por exemplo:
var
MeusDados: Inteiro;
MinhaString: string ;
Você pode declarar múltiplas variáveis do mesmo tipo na mesma linha:
var
ArraySize, ArrayCount: Inteiro;
Este hábito de declaração não é recomendado em declarações de classe.
8.1.3 Declaração de array
É comum sempre colocar um espaço antes do colchete de abertura e depois do colchete de fechamento:
tipo
TMyArray = array [0..100] de Char;
8.2.3 instrução if
A instrução if deve aparecer em pelo menos duas linhas:
Por exemplo:
//erro:
se A = B então faça alguma coisa;
//correto
se A = B então
Faça alguma coisa;
Se for uma instrução if composta, deverá haver uma nova linha para cada delimitador:
//erro:
se A = B então comece
Faça alguma coisa;
Faça outra coisa;
fim senão começo
Faça isso;
Faça isso;
fim ;
//correto
se A = B então
começar
Faça alguma coisa;
Faça outra coisa;
fim
outro
começar
Faça isso;
Faça isso;
fim ;
Algumas variações do seguinte podem ser adotadas:
//correto
se Condição então
começar
Faça isso;
fim mais
começar
Faça isso;
fim ;
//correto
se Condição então
começar
Faça isso;
fim
outro
Faça alguma coisa;
//correto
se Condição então
começar
Faça isso;
fim mais
FaçaSoemthing;
//O método a seguir pode não ser importante, mas é digno de elogio:
se Condição então
Faça isso
senão faça isso;
8.2.4 para declaração
Exemplo:
//INCORRETO
para i := 0 a 10 comece
Faça alguma coisa;
Faça outra coisa;
fim ;
// CORRETO
para eu := 0 a 10 faça
começar
Faça alguma coisa;
Faça outra coisa;
fim ;
8.2.5 declaração while
Exemplo:
//INCORRETO
enquanto x < j começa
Faça alguma coisa;
Faça outra coisa;
fim ;
// CORRETO
enquanto x < j faz
começar
Faça alguma coisa;
Faça outra coisa;
fim ;
8.2.6 repetir até declaração
Exemplo:
// CORRETO
repita
x := j;
j := AtualizarValor;
até j = 25;
8.2.7 declaração de caso
Exemplo:
// CORRETO
controle de caso.Alinhamento de
alLeft, alNone: NewRange := Max(NewRange, Posição);
tudo bem: Inc(AlignMargin, Control.Width);
fim ;
// CORRETO
caso x de
CSSInício:
começar
j := AtualizarValor;
fim ;
csBegin: x := j;
csTimeOut:
começar
j :=x;
x := AtualizarValor;
fim ;
fim ;
// CORRETO
caso ScrollCode de
SB_LINEUP, SB_LINEDOWN:
começar
Incr := FIncremento div FLineDiv;
FinalIncr := FIncremento mod FLineDiv;
Contagem := FLineDiv;
fim ;
SB_PAGEUP, SB_PAGEDOWN:
começar
Incr := FPageIncrement;
FinalIncr := Incr mod FPageDiv;
Incr := Incr div FPageDiv;
Contagem := FPageDiv;
fim ;
outro
Contagem := 0;
Incr := 0;
FinalIncr := 0;
fim ;
8.2.8 instrução try
//Correto
tentar
tentar
EnumThreadWindows(CurrentThreadID, @Disable, 0);
Resultado:= TaskWindowList;
exceto
EnableTaskWindows(TaskWindowList);
elevação ;
fim ;
finalmente
TaskWindowList := SaveWindowList;
TaskActiveWindow := SaveActiveWindow;
fim ;
Blog do autor: http://blog.csdn.net/sailerbai/