r4 - 07 Aug 2007 - NelsonFerraz
NOME
perlstyle - Guia de Estilos de PerlDESCRIÇÃO
Cada programador tera claramente as suas proprias preferencias quanto a formatacao de codigo, mas existem algumas normas que tornam os programas mais faceis de serem lidos, entendidos e mantidos. O mais importante e executar programas usando sempre a flag -w. Voce pode explicitamente desactiva-la em porcoes de codigo usando o pragmano warnings ou atraves variavel $^W se desejar. Voce deve sempre executar o seu codigo usando o pragma use strict ou saber a razao proque nao o deve fazer. Os pragmas use sigtrap e use diagnostics podem tambem ser importantes.
Em relacao a estetica do lay out de codigo, a unica coisa com que Larry se preocupa fortemente e que fecho das chavetas num block de multiplas linhas esteja alinhado com o comando que deu inicio ao bloco. Para alem disso ele tem outras preferencias nas quais ele nao e tao exigente.
-
Identacao de 4 colunas.
Se possivel abria as chavetas na mesma linha da keyword, caso nao seja possivel alinhe-a.
Um espaco antes de abrir a chaveta num bloco de multiplas linhas.
Um bloco de uma linha pode ser colocado numa unicalinha de codigo incluindo o abrir e fechar das chavetas.
Nenhum espaco deve estar antes do ponto e virgula.
Voce pode omitir o ponto e virgula se o seu block so tiver uma linha de codigo.
Colocar espacos antes e depois da maioria dos operadores.
Colocar um espaco antes e depois de subscripts complexos (destro de colchetes).
Colocar linhas em branco entre pedacos de codigo que tem funcionalidades diferentes.
Colocar o statment else na linha posterior ao fecho da chaveta do statment if.
Exemplo:
if (...) {
...
}
else {
...
}
Sem espaco entre o nome de uma funcao e o abrir parenteses.
Colocar um espaco depois de cada virgula.
As linas de codigo logas devem ser quebradas depois de um operador (a excepcao de ``and'' e ``or'').
Colocar um espaco despois de cada abertura e fecho de parentesis que estejam na mesma linha.
Alinhar verticalmente os items correspondentes.
Desde que a clareza do codigo nao seja comprometida deve-se omitir a pontucao redundante.
Larry tem as suas razoes para cada uma destas normas, mas nao pede que todos trabalhem da mesma forma que ele.
Abaixo encontram-se outras questoes acerca de estilos a serem consideradas:
-
So porque eu <POSSO> fazer algo de um modo em particular isso nao quer dizer que eu <DEVA> faze-lo dessa forma. O Perl foi desenhado para lhe permitir fazer o que quizer, assim sendo, escolha o modo mais legivel de o fazer. Por exemplo
open(FOO,$foo) || die "Erro ao abrir $foo: $!";
e melhor que
die "Erro ao abrir $foo: $!" unless open(FOO,$foo);
porque a segunda forma esconde o objectivo do statment num modificador. Por outro lado
print "Iniciando analises\n" if $verbose;
e melhor que
$verbose && print "Iniciando analises\n";
porque a questao nao e ser o usuario digitou -v ou nao.
Similarmente, so porque um operador permite-lhe assumir argumentos por defeito isto nao quer dizer que voce tenha que usar os parametros por defeito. Os parametros por defeito sao para programadores preguicosos que escrevem programas sem grande importancia. e voce deseja que o seu programa seja legivel, forneca o argumento.
Dentro da mesma linha de estilo, so porque eu <POSSO> omitir os parenteses nao que dizer que eu o faca:
return print reverse sort num values %array;
return print(reverse(sort num (values(%array))));
Quando em duvida ponha parenteses. No minimo ira permitir que um programador descuidado se descuide com a tecla % no vi.
Mesmo que nao tenha duvidas, tenha em consideracao a saude mental da pessoa que ira manter o seu codigo e que ira provavelmente colocar parenteses no lugar errado.
Nao faca contorcionismos para sair de um loop no seu inicio ou fim, quando o Perl possui o operador last para que voce possa sair no meio do mesmo. Faca somente uma pequena ``desidentacao'' para que seja mais visivel.
LINE:
for (;;) {
statements;
last LINE if $foo;
next LINE if /^#/;
statements;
}
ao tenha medo de usar loop labels--eles existem para aumentar a legibilidade assim como permitir varios niveis de saida de loops. Veja o exemplo anterior.
Evite usar grep() (ou map()) ou `backticks` num contexto vazio, quer dizer, quando voce descarta o valor de retorno. Todas estas funcoes possui valores de retorno, logo, use-o. Caso o contrario use um loop foreach() ou a funcao system().
Por uma questoa de portabilidade de codigo, quando usar funcionalidades que nao estejam implementadas em todos os computadores, teste o construtor/funcao com um eval para verificar se existe falha. Se voce souber que versao ou patchlevel em que uma funcionalidade foi implementada voce podera testa-la com $] ($PERL_VERSION in English) de modo a verificar a sua existencia. O modulo Config tambem permite a verificacao de valores determinados pelo Configure quando o Perl foi instalado.
Escolha identificadores claros. Se voce nao sabe o que isso quer dizer, entao voce tem um problema.
Enquanto identificadores curtos como $gotit servem, use underscores para separar palavras. E de forma geral mais facil de ler $var_names_like_this do que $VarNamesLikeThis especialmente para pessoas de lingua nao inglesa.
Nomes de pacotes aso normalmente uma excepcao a esta regra. O Perl, de uma forma informal, reserva nomes com letras minusculas para modulos ``pragma'' como integer e strict. Outros modulos devem iniciar o seu nome com uma letra maiuscula e usar letras minusculas e maiusculas, mas provavelmente sem underscores devido a uma limitacao imposta pela representacao dos nomes dos modulos em sistemas de ficheiros primitivos que necessitam de caber em apenas alguns bytes.
Podera ser util usar o letras maiusculas ou minusculas para indicar o significado ou natureza de uma variavel. Por exemplo:
$LETRAS_MAISCULAS_AQUI somente em constantes (cuidado para nao coincidir com variaveis internas do Perl!)
$Algumas_Letras_Maiusculas_Aqui Variaveis Globais/Estaticas ou que sejam usadas por todo o pacote.
$sem_letras_maiusculas_aqui Variavies de escopo da funcao C<my()> ou C<local()>.
Nomes de funcoes ou metodos parecem melhor se forem completamente em letras minusculas.
Ex: $obj->as_string().
Voce pode usar um underscore como primeiro caracter de uma variavel para indicar que esta nao deve ser usada fora do pacote onde foi definida.
Se voce tiver uma expressao regular cabeluda, use o modificador /x e ponha alguns espacos em branco para melhorar a sua legibilidade. Nao use ``/'' ou ``\'' como separadores quando a sua regexp contem ``/'' ou ``\'' ela propria.
Use o novo operador and e or para evitar usar tantos parenteses naos operadores de listas e para reduzir a incidencia de operadores de pontuacao como && e ||. Chame as suas subrotinas como se fossem funcoes ou operadores de lista de forma a evitar o excesso de ``&'' e parenteses.
Use here documents instead of repeated print() statements.
Alinhe verticalmente o seu codigo especialmente se for demasiado longo para caber em uma unica linha.
$IDX = $ST_MTIME;
$IDX = $ST_ATIME if $opt_u;
$IDX = $ST_CTIME if $opt_c;
$IDX = $ST_SIZE if $opt_s;
mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!";
chdir($tmpdir) or die "can't chdir $tmpdir: $!";
mkdir 'tmp', 0777 or die "can't mkdir $tmpdir/tmp: $!";
Verifique sempre o valor de retorno de uma system call. Uma mensagem de error deve sempre ir mata o STDERR, inclua que programa causou o problema, que system call falhou e que algumentos foram usados e (MUITO IMPORTANTE) deve conter a mensagem de systema por defeito com o que correu mal. Aqui aprentams um exemplo simples mas suficiente:
opendir(D, $dir) or die "can't opendir $dir: $!";
Alinhe sempre as suas transliteracoes quando isso fizer sentido.
tr [abc]
[xyz];
Pense sempre em reusabididade. Porque desperdicar codigo quando voce podera reutilizar o codigo mais tarde noutro programa? Pense em codigo generico. Pense na construcao de modulos ou classes. Pense sempre em utilizar use strict e <use warnings> (ou -w) de forma ao seu codigo ser executado de uma forma limpa. Pense em distrubuir o seu codigo. Pense em mudar o modo como ve o mundo. Pense em... deixa p'ra la.
Seja consistente.
Seja bom.
