Especificações de codificação Delphi Autor: Tulipsys Data de atualização: 16 de dezembro de 2003 Conteúdo 1. Convenções gerais (nomeação - recuo e espaços - margens - maiúsculas e minúsculas - comentários) 2. Instrução (início...fim instrução-se instrução-caso instrução-para instrução-enquanto instrução-repetição instrução-com instrução-instrução de tratamento de exceção) 3. Procedimentos e funções (nomeação e formato-parâmetros formais-variáveis-tipo-tipos personalizados) 4. O objetivo de formular padrões de codificação relacionados à orientação a objetos (nomeação de classes e implementação de método de formato-campo-método-propriedade-método) é permitir que um grupo de programadores gere código do mesmo estilo, para que uma equipe possa formar e manter um certo estilo. Se esse objetivo for alcançado, todos os arquivos do projeto parecerão que foram escritos por um programador. Ainda bem que é divertido, mas a vantagem é que o código de cada programador é fácil de entender pelos outros, o que melhorará muito a capacidade de manutenção do código e, portanto, reduzirá os custos de manutenção. Esta é uma situação ideal para qualquer equipe. Para os indivíduos, escolher ou autogerar uma norma de codificação e aderir a essa norma também pode produzir bons resultados. A propósito, este é um objetivo muito tentador, mas não muito difícil de alcançar. Cada linguagem de programação tem seus próprios padrões de codificação. Pode-se dizer que os padrões de codificação são um resumo da experiência. É claro que também devemos aprender com os padrões de outras linguagens de programação. Portanto, é muito importante aprender com os outros. Em segundo lugar, o uso de padrões de codificação visa simplificar o trabalho dos programadores. O significado de “simplificação” não é reduzir a quantidade de código (pelo contrário, muitas vezes seguir os padrões trará mais código), mas sim reduzir a quantidade de código do programador. trabalho na manutenção da quantidade. A programação é um trabalho muito complexo. É assustador lidar com vários relacionamentos e há vários relacionamentos inextricáveis. Os programadores devem gastar a maior parte de sua energia lidando com relacionamentos e evitando perder tempo com questões muito detalhadas. Se ele conseguir entender rapidamente a ideia e a estrutura do programa, um plano de manutenção será formado rapidamente. Além disso, o padrão de codificação deve ser um padrão muito fácil de usar, que você possa consultar e modificar, mas deve ser fácil de usar. Mas em grupo, certifique-se de que todos usem os mesmos padrões. A programação é um trabalho muito flexível Somente com pensamento flexível e aplicação flexível podem ser obtidos bons resultados. Além disso, o uso de especificações visa em grande parte reduzir a carga de memória dos programadores. A capacidade de raciocínio humano é extremamente excelente, mas a memória é muito fraca. Enfrentamos computadores o dia todo, e a coisa mais importante que ele quer nos ajudar é a memória. Portanto, um dos nossos objetivos é maximizar as vantagens de pensamento dos programadores. Por fim, as ferramentas de programação têm grande influência nos padrões de codificação, e essa influência vem do estilo de programação do desenvolvedor. Também baseado em C++, não usaremos exatamente as mesmas especificações de codificação no Microsoft Visual C++ e no Borland C++ Builder. Microsoft e Borland têm estilos diferentes e muito distintos. Como usuários, podemos fazer alterações com base nisso, mas há limites. Na verdade, quando fazemos escolhas sobre fornecedores e ferramentas de desenvolvimento, também determinamos nosso estilo futuro. 1. Convenções gerais 1.1 Nomenclatura O princípio básico da nomenclatura é que o nome deve expressar claramente a função dos dados. Object Pascal suporta nomes de arquivos longos. Os nomes devem usar verbos, substantivos ou uma combinação de ambos. Você não deve usar palavras reservadas e palavras-chave definidas em Delphi e tentar não usar palavras reservadas e palavras-chave definidas em outras linguagens. Tente usar palavras completas e evite abreviações, prefixos e sufixos, sublinhados ou outros símbolos da nomenclatura húngara. As convenções de nomenclatura são usadas para garantir a legibilidade dos nomes. Os padrões de nomenclatura representados pela nomenclatura húngara desenvolveram muitos prefixos e sufixos para indicar o tipo, escopo ou outros atributos diversos dos dados. No Delphi, você certamente pode usar esse método, mas não é um método recomendado. Uma razão é que esse tipo de convenção de nomenclatura traz muitas tarefas adicionais de memória, e outra razão é determinada pelas características do próprio Delphi. A verificação de tipo obrigatória do Delphi monitorará automaticamente o uso de todas as variáveis, então só precisamos prestar um pouco de atenção (prestar atenção à capitalização das palavras) sem ter que adicionar laboriosamente vários prefixos. Além disso, a consideração dos dados deve basear-se no significado e não no tipo ou âmbito, e a atenção deve ser colocada na estrutura do programa, nas relações lógicas e nas ideias de concepção. Portanto, no Delphi você só precisa usar uma combinação completa de palavras para nomear, não considere mais nada e, claro, você deve mantê-lo o mais conciso possível. Em algumas instruções (como loops for) precisamos usar vários números inteiros como variáveis de contagem. Aqui você pode simplesmente usar as três letras i, j e k como nomes de variáveis. Este é um hábito que foi desenvolvido e mantido na linguagem Fortran e tem se mostrado muito útil e de fácil compreensão. Claro, teríamos melhores resultados usando um nome mais significativo, como: MyCounter. De modo geral, as três letras i, j e k são completamente suficientes, caso contrário, mais processos ou funções deverão ser divididos. Aqui estão alguns exemplos: 1. SongsList //Indica que esta é uma lista de músicas. O número plural da música indica que há mais de uma música. 2. SetCarColor //Indica que esta é uma função para definir a cor. o carro. Se uma classe TCar for definida, então SetColor será usado na classe como um membro da função para definir a cor do carro. Preste atenção também à nomenclatura das variáveis booleanas. O nome de uma variável booleana deve indicar claramente o significado de Verdadeiro e Falso. Por exemplo, para uma variável que registra se um arquivo existe, usar IsFileExisted é melhor do que usar FileExisted. Finalmente, nunca nomeie uma variável global como Temp ou Tmp, mas ela ainda é permitida dentro de um procedimento ou função. Na verdade, há um pouco de controvérsia sobre esta regra. Alguns padrões de codificação são mais rígidos. Essa nomenclatura é absolutamente proibida, mesmo em procedimentos ou funções. Porém, muitas vezes essa nomenclatura é realmente conveniente, principalmente para procedimentos ou funções. Se for usado como uma variável global, é provável que haja uma instrução de atribuição que não corresponda ao tipo. Embora o compilador lhe dê muita ajuda neste momento, é difícil evitar a ocorrência de pequenos erros. . Em resumo, seguir esta regra produzirá melhores resultados, mas nada deve ser rigorosamente respeitado se necessário. 1.2 Indentação e Espaços Dois espaços deverão ser recuados entre cada nível. Isto tornará o programa claro e bem organizado. Nunca use caracteres de tabulação, porque é difícil manter a largura dos caracteres de tabulação consistente com diferentes configurações e aplicativos, mas não espere que seu programa seja visualizado apenas no Delphi. Preste atenção também ao uso do editor. Se você escolher apenas Delphi, então não há problema se você também usar um processador de texto como o Word, preste atenção ao usar fontes apropriadas para garantir a largura de cada letra e símbolo; é o mesmo. Ao imprimir com um processador de texto como o Word, você também deve prestar atenção à seleção das fontes. O uso de espaços também serve para manter o programa limpo e permitir que os programadores entendam rapidamente a estrutura do programa. A seguir estão algumas especificações e exemplos correspondentes: 1. Deve haver um espaço entre cada palavra. Por exemplo: para TMyClass = class(TObject)2． Deve haver um espaço ao redor de "=", "<>", ">=" e "<="; deve haver um espaço à direita de ":=" e ":", mas não à esquerda. Por exemplo: se a = b então a:= b; Deve haver um espaço entre palavras reservadas e palavras-chave e o símbolo à esquerda, mas nenhum espaço entre elas e o símbolo à direita. Por exemplo: sobrecarga de PRocedure ShowMessage;4. Uso de colchetes: Na definição e chamada de procedimentos e funções não devem ser deixados espaços entre colchetes e palavras e símbolos externos. Não devem ser deixados espaços entre colchetes e palavras internas; No julgamento condicional da instrução if, devem ser usados espaços entre palavras reservadas como e e ou. Por exemplo: function Exchange(a: inteiro; b: inteiro); if (a = b) and ((a = c) ou (a = d)) then… end;1.3 margem O editor Delphi está a cerca de 81º da direita. é uma linha escura deixada no caractere Na verdade, na interface padrão do Delphi, quando a resolução é 800*600, a janela maximizada será exibida 4 letras à esquerda da linha escura. Portanto, não escreva o código-fonte fora da linha escura, o que significa que cada linha não deve exceder 80 caracteres, incluindo espaços iniciais e intermediários. Se a instrução for muito longa, a quebra de linha será concluída e deverá ser recuada por dois caracteres. Também é fácil de imprimir e as partes além da linha escura não serão impressas no Delphi. Se você usar um software de processamento de texto como o Word para imprimir um programa Delphi, a parte excedente será movida para o início da próxima linha, dificultando a leitura do programa impresso. Portanto, procure fazer todos os ajustes enquanto escreve o código, e não deixe esse tipo de trabalho para impressão. Ao quebrar as linhas, preste atenção em manter a legibilidade do programa e tente manter a parte completa. Por exemplo, se a função for muito longa, envolva uma descrição completa do parâmetro em vez de apenas a declaração do tipo de dados. As duas primeiras formas de escrever abaixo estão corretas e as seguintes formas de escrever estão erradas: function AdditonFiveInputNumber(a: inteiro; b: inteiro; c: inteiro; d: ineger;e: inteiro): inteiro //Função correta AdditonFiveInputNumber; (a: inteiro;b: inteiro;c: inteiro;d: ineger;e: inteiro): inteiro //Função correta; AdditonFiveInputNumber(a: inteiro; b: inteiro; c: inteiro; d: ineger; e: inteiro): inteiro; //Função de erro AdditonFiveInputNumber(a: inteiro; b: inteiro; c: inteiro; d: ineger;e: inteiro ): inteiro; //Função de erro AdditonFiveInputNumber(a: inteiro; b: inteiro; c: inteiro; d: ineger;e: inteiro): inteiro; //Erro 1.4 A primeira letra de cada palavra no nome personalizado deve ser maiúscula e minúscula, e as demais letras devem ser minúsculas. Palavras reservadas e palavras-chave do Delphi devem estar todas em minúsculas. O método de escrita de funções predefinidas do Delphi é igual ao método de escrita de nomes personalizados. Os tipos de dados básicos no Delphi devem estar em letras minúsculas e as duas primeiras letras dos tipos de classe estendidas devem estar em maiúscula (a primeira letra de um tipo de classe é "T"). Aqui estão alguns exemplos: 1. Nome personalizado: MyFavouriteSong, CarList 2. Palavras reservadas: if (a = b) and ((a = c) ou (a = d)) then … end; ('Tudo certo');4. Tipo de classe de extensão Delphi: MyStrings = TStrings.Create;1.5. Comentários O Delphi suporta dois tipos de comentários: comentários em bloco ({}) e comentários de linha única (//). O objetivo dos comentários é explicar as ideias de design do programa e ajudar os programadores a compreender as ideias do programa escrito há dois anos ou mesmo ontem o mais rápido possível. Na verdade, isso é para resolver o problema da memória. O cérebro não deve ser usado demais como memória. Nunca confie muito no cérebro na programação, mas use palavras tanto quanto possível. Portanto, os comentários são um aspecto muito importante nas linguagens de programação, embora muitas pessoas (especialmente iniciantes, incluindo um número considerável de programadores) não se importem com isso e raramente escrevam comentários. Outra aplicação de comentários está na fase de depuração do programa. Por exemplo, se houver duas instruções e você não souber qual é a melhor com antecedência, será necessário testar: coloque "//" antes de uma instrução (ou seja, altere). a declaração para comentar), executar outra declaração e depois fazer o oposto, podemos facilmente fazer a escolha. Se for um grupo de declarações, use comentários em bloco, mas certifique-se de colocar "{" e "}" em posições de destaque, como em linhas superiores e inferiores separadas. A seguir estão alguns princípios de uso: 1. Na maioria dos casos, é necessário colocar comentários antes das variáveis e tipos personalizados. 2. Na maioria dos casos, é necessário colocar um comentário no topo do arquivo da unidade. Aqui, o comentário deve incluir: nome do arquivo, data de criação, data de modificação, autor, autor da modificação e descrição necessária. 3. Os comentários devem ser significativos, não use comentários inúteis. Por exemplo: enquanto i < 8 dobegin … i:= i + 1; //Adicione um ao iend; o comentário "//Adicione um ao i" não tem sentido aqui, é claro que não significa uma declaração simples (semelhante a: i : = i + 1) nenhum comentário é necessário. Como afirmações simples muitas vezes desempenham um papel muito importante, se esta afirmação faz as pessoas questionarem ou é difícil de compreender, então a função desta afirmação deve ser assinalada. 4. Não tente criar monogramas nos comentários, a menos que você ache absolutamente necessário. Porque é muito difícil modificar a anotação mantendo o padrão intacto e bonito. . 5. Para distinguir comentários temporários de comentários permanentes, você pode usar seu método para colocar símbolos especiais nos comentários. A vantagem disso é que é fácil de encontrar. 6. As alterações nas declarações são mapeadas para os comentários correspondentes. 7. Deve haver uma lacuna clara entre os comentários e o código, para que você possa saber rapidamente o que é uma declaração e o que é um comentário. Você pode colocar comentários na linha antes ou depois da linha do código, ou deixar pelo menos dois espaços imediatamente após o código. Porém, quando o código e os comentários estiverem na mesma linha, não coloque o código após o comentário. não coloque o código após o comentário. Os comentários são colocados no meio do código.