Perl - padrão de codificação

Cada programador terá, é claro, suas próprias preferências em relação à formatação, mas existem algumas diretrizes gerais que tornarão seus programas mais fáceis de ler, entender e manter.

O mais importante é executar seus programas com a opção -w o tempo todo. Você pode desativá-lo explicitamente para partes específicas do código por meio do pragma no warnings ou da variável $ ^ W, se necessário. Você também deve sempre executar sob uso estrito ou saber o motivo. O uso de sigtrap e até mesmo o uso de pragmas de diagnóstico também podem ser úteis.

Com relação à estética do layout do código, a única coisa com a qual Larry se preocupa muito é que a chave de fechamento de um BLOCO de várias linhas deve se alinhar com a palavra-chave que iniciou a construção. Além disso, ele tem outras preferências que não são tão fortes -

  • Recuo de 4 colunas.
  • Abrindo as curvas na mesma linha da palavra-chave, se possível, caso contrário, alinhe.
  • Espaço antes da curva de abertura de um BLOCO de várias linhas.
  • O BLOCO de uma linha pode ser colocado em uma linha, incluindo cachos.
  • Sem espaço antes do ponto e vírgula.
  • Ponto-e-vírgula omitido no BLOCO "curto" de uma linha.
  • Espaço em torno da maioria dos operadores.
  • Espaço ao redor de um subscrito "complexo" (entre colchetes).
  • Linhas em branco entre pedaços que fazem coisas diferentes.
  • Elses relaxados.
  • Sem espaço entre o nome da função e seu parêntese de abertura.
  • Espaço após cada vírgula.
  • Longas linhas interrompidas após um operador (exceto e e ou).
  • Espaço após a correspondência do último parêntese na linha atual.
  • Alinhe os itens correspondentes verticalmente.
  • Omita a pontuação redundante, desde que a clareza não seja prejudicada.

Aqui estão algumas outras questões de estilo mais substantivas para se pensar: Só porque você PODE fazer algo de uma maneira particular, não significa que você DEVE fazer dessa maneira. Perl é projetado para fornecer várias maneiras de fazer qualquer coisa, então considere escolher a mais legível. Por exemplo -

open(FOO,$foo) || die "Can't open $foo: $!";

É melhor que -

die "Can't open $foo: $!" unless open(FOO,$foo);

Porque a segunda maneira esconde o ponto principal da instrução em um modificador. Por outro lado,

print "Starting analysis\n" if $verbose;

É melhor que -

$verbose && print "Starting analysis\n";

Porque o ponto principal não é se o usuário digitou -v ou não.

Não faça contorções bobas para sair de um loop no topo ou no fundo, quando Perl fornece o último operador para que você possa sair no meio. Apenas "afaste" um pouco para torná-lo mais visível -

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

Vamos ver mais alguns pontos importantes -

  • Não tenha medo de usar rótulos de loop - eles estão lá para melhorar a legibilidade e também para permitir quebras de loop em vários níveis. Veja o exemplo anterior.

  • Evite usar grep () (ou map ()) ou `backticks` em um contexto vazio, ou seja, quando você simplesmente joga fora seus valores de retorno. Todas essas funções têm valores de retorno, então use-os. Caso contrário, use um loop foreach () ou a função system ().

  • Para portabilidade, ao usar recursos que podem não ser implementados em todas as máquinas, teste a construção em uma avaliação para ver se falha. Se você sabe qual versão ou nível de patch de um recurso específico foi implementado, você pode testar $] ($ PERL_VERSION em inglês) para ver se ele estará lá. O módulo Config também permitirá que você interrogue os valores determinados pelo programa Configure quando o Perl foi instalado.

  • Escolha identificadores mnemônicos. Se você não consegue lembrar o que significa mnemônico, você tem um problema.

  • Embora identificadores curtos como $ gotit provavelmente sejam adequados, use sublinhados para separar palavras em identificadores mais longos. Geralmente é mais fácil ler $ var_names_like_this do que $ VarNamesLikeThis, especialmente para falantes não nativos de inglês. É também uma regra simples que funciona de forma consistente com VAR_NAMES_LIKE_THIS.

  • Os nomes dos pacotes às vezes são uma exceção a esta regra. Perl reserva informalmente nomes de módulos em minúsculas para módulos "pragma" como integer e strict. Outros módulos devem começar com uma letra maiúscula e usar maiúsculas e minúsculas, mas provavelmente sem sublinhados devido às limitações nas representações dos nomes dos módulos dos sistemas de arquivos primitivos como arquivos que devem caber em alguns bytes esparsos.

  • Se você tiver uma expressão regular realmente complicada, use o modificador / x e coloque alguns espaços em branco para que pareça um pouco menos com ruído de linha. Não use barra como delimitador quando sua regexp tiver barras ou barras invertidas.

  • Sempre verifique os códigos de retorno das chamadas do sistema. Boas mensagens de erro devem ir para STDERR, incluir o programa que causou o problema, quais foram os argumentos e a chamada do sistema com falha e (MUITO IMPORTANTE) deve conter a mensagem de erro padrão do sistema para o que deu errado. Aqui está um exemplo simples, mas suficiente -

opendir(D, $dir) or die "can't opendir $dir: $!";

  • Pense na capacidade de reutilização. Por que desperdiçar capacidade intelectual em um tiro único quando você pode querer fazer algo assim novamente? Considere generalizar seu código. Considere escrever um módulo ou classe de objeto. Considere fazer seu código funcionar de maneira limpa com use estrito e avisos de uso (ou -w) em vigor. Considere distribuir seu código. Considere mudar toda a sua visão de mundo. Considere ... oh, não importa.

  • Ser consistente.

  • Seja legal.