Os padrões de codificação fornecem principalmente à equipe de desenvolvimento uma diretriz de programação para que os desenvolvedores do projeto tenham um formato consistente a seguir durante a programação. Desta forma, o código escrito por cada programador da equipe de desenvolvimento pode ser compreendido por outros, melhorando assim a manutenibilidade do código, tornando um conjunto de software escrito por várias pessoas como se tivesse sido escrito por uma pessoa, tornando o código mais fácil entender. Isso exige que todos usem um estilo de codificação consistente. Bem, a razão pela qual é clichê introduzir esses padrões é porque quando novos desenvolvedores se juntam à equipe de desenvolvimento do projeto, alguns podem não estar familiarizados com os padrões de codificação do Delphi. Esses padrões serão apresentados aqui nas seguintes categorias: 1. Regras gerais de formato de código-fonte 2. Procedimentos e funções 3. Nomeação de arquivos, formulários e módulos de dados 4. Nomenclatura de pacotes e componentes Regras gerais de formato de código-fonte O recuo é cada nível Existem dois espaços entre eles. 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.). Margens 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. Os colchetes não têm 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. CallPRocedure(Parameters); // Errado! CallProcedure (Parameters); // Palavras reservadas e palavras-chave Object As palavras reservadas e palavras-chave da linguagem Pascal estão sempre em letras minúsculas. A instrução start...endbegin deve estar em sua própria linha. Por exemplo, a primeira linha abaixo está errada, mas a segunda linha está correta: for i:=0 to 10 do BeginStatement end// Errado, o início está na mesma linha que for i:=0 to 10 do //Correct ! Begin in Um caso especial desta regra em BeginStatementeend em outra linha é quando Begin faz parte de uma instrução else. Por exemplo: if Condition thenbeginStatement endelse BeginStatement; a instrução endend 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. Declaração (1) A situação mais provável da instrução if_then_else deve ser colocada na cláusula then, e a situação improvável deve ser colocada 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. No código-fonte, os parênteses são usados apenas quando realmente necessários. Por exemplo: if (I=42) then // Errado, os parênteses são redundantes if (I=42) ou (J=42) then // Correto, os parênteses devem ser usados Se houver múltiplas condições para testar na instrução if, você deve organizar 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. 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 deverá ser construída assim: if Condição1 e Condição2 e Condição3 then(2) instrução case_else As constantes para cada caso na instrução case devem ser organizadas em ordem numérica ou alfabética ordem. 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 de uma instrução case é usada apenas para casos padrão ou detecção de erros. (3) A instrução while recomenda não usar o processo de saída 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) instrução for Se o número de loops for determinado, a instrução for deve ser usada em vez da instrução while. (5) instrução de repetição A instrução de repetição é semelhante a um loop while e segue as mesmas regras. (6) instrução with 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 essas situações podem facilmente confundir os programadores e dificultar a depuração. Tratamento estruturado de exceções 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. (1) Uso de try...finally Sempre que possível, cada alocação de recurso deve corresponder à estrutura try...finally. Por exemplo: //O código a seguir pode causar erros SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;//Uma solução segura para o recurso acima a alocação é: SomeClass1: = TSomeClass Create;trySomeClass2: = TSomeClass Create;try{fazer algum código}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) Uso de try...except Se desejar executar algumas tarefas 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. (3) O uso de try...except...else é desencorajado do uso de try...except com uma cláusula else, porque isso bloqueará todas as exceções, incluindo exceções que você não está preparado para tratar.