[Cascavel-pm] Perl - Cases

[Adriano Ferreira]

On 4/24/07, Eden Cardim <edencardim em gmail.com> wrote:
> On 4/24/07, Thomas Britis <thomas em tcnet.com.br> wrote:
>
> > > <trecho de código de um .cgi do bugzilla>
> > > use strict;
> > >
> > > use lib qw(.);
> > >
> > > require "globals.pl";
> > > </trecho de código de um .cgi do bugzilla>
> > >
> > > Realmente tá feia a coisa... Desisti de ler o resto do código depois
> > > de ler essas três linhas iniciais...

Olha o exagero, pessoal! O BugZilla é um projeto open-source e se não
tem dinheiro custeando o desenvolvimento, trabalha-se nele quando
possível e quando é agradável. Ah, e também do jeito que a experiência
dos desenvolvedores em atividade favorece. Refactoring de código nunca
foi agradável - a tendência do "se funciona, vamos em frente" é muito
grande.

Se tem dinheiro custeando o desenvolvimento, pode ser que o
patrocinador não insista no melhoramento da qualidade do código e
assim o foco pode cair na evolução e criação de novas funcionalidades.
Claro que de remendo em remendo, um dia a casa cai e alguém vai
precisar abrir um outro projeto para refazer o BugZilla e tantos
outros projetos.

Os pecados do código fonte estão por todos os lados, principalmente
nos projetos maiores. Como o próprio interpretador Perl, por exemplo.
Por exemplo, eu me lembro de alguns desenvolvedores do core que
abominavam as partes do PerlIO. E não foi qualquer um que escreveu o
PerlIO, foi o falecido Nick Ing-Simmons que escreveu o módulo Tk
também.

> > Eden,
> >
> >         Boa tarde.
> >
> >         Qual seria(m) o(s) problema(s) desse trecho de código?
> >
> >         Atenciosamente,
>
> - falta um < use warnings > depois do < use strict > para evitar dores
> de cabeça num projeto do tamanho do bugzilla

Este problema acompanha de perto o terceiro que comento logo abaixo.

> - < use lib qw(.) > ao meu ver, está sendo usado para adaptar a
> estrutura mal-definida (segundo os meus critérios individuais) do
> código, que mistura bibliotecas (.pl = perl library) com executáveis
> (.cgi). Se não me falha a memória, ter o diretório atual no @INC dá
> vazão a falhas de segurança, tanto é que Perl não coloca o '.' no @INC
> se o taint mode estiver ligado.

Este eu não consigo justificar não.

> - < require "globals.pl" > tem dois problemas. Primeiro, usar globais
> é má prática vastamente conhecida. Nem abri o arquivo globals.pl, mas
> se por acaso ele não contém nada global, o nome não suficientemente
> descritivo, o que é ruim do mesmo jeito. Segundo, "globals.pl" está
> escrito com aspas duplas, o que obriga o compilador a analisar
> inutilmente a string em busca de candidatos a interpolação. Isso
> prejudica bastante o desempenho de uma aplicação cgi, já que o
> programa inteiro é recompilado cada vez que se faz uma requisição.

< require "globals.pl" > é coisa de Perl 4, o que sugere que o
BugZilla já está com os cabelos brancos e, na sua evolução, não foi
modernizado para Perl 5. Acho que são problemas comuns em
distribuições que não estão no formato comum utilizado no CPAN
onde o mantra deve valer

     perl Makefile.PL
     make
     make test
     make install

Não estar no CPAN é o caso de alguns projetos importantes: como o
binding Perl ao Subversion, WebGUI, Movable Type e outros. E para
dizer a verdade, depois que você se acostuma a comodidade das
distribuições CPAN, é aborrecido por exemplo conseguir os bindings
Perl para Subversion de uma outra forma que não "cpan install
SVN::Core".

Mas assim é a vida. Melhorem os seus projetos open-source favoritos.
Continuem a falar daqueles que os incomodam.

Adriano.

> --
> Eden Cardim
> Instituto Baiano de Biotecnologia
> Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas
> Laboratório de Bioinformática
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>