[SP-pm] HERE-DOCS: Forma culta ? Quando usar ?

Alexei Znamensky russoz at gmail.com
Thu Nov 13 03:47:54 PST 2008


Fields,

Eu vou fazer um contra-ponto aqui com você. Eu acho que o que você escreveu
faz muito sentido, MAS depende do contexto. Você, e vários outros aqui,
desenvolvem sistemas de médio a maior porte. Separar a implementação das
regras de negócio de um blocão de conteúdo estático faz todo o sentido do
mundo num contexto desses.

Mas em programas pequenos, e aqui estou pensando naqueles scripts que eu
faço e que são muito simples, não vale a pena fazer isso. O exemplo de
"usage" é perfeito para isso, e é exatamente o que faço nos meus scripts.

my $0.02

[]s

2008/11/13 Luis Motta Campos <luismottacampos em yahoo.co.uk>

> Bruno Borela wrote:
>
>> Do livro "Perl Best Practices" do Damian Conway:
>>
>>  The "break-after-newlines-and-concatenate" approach is fine for a small
>>> number of lines, but it starts to become inefficient - and
>>> ugly - for larger chunks of text.
>>>
>>
> Bom, eu acho que eu tenho poder de fogo para discordar do  Damian Conway.
> :) Eu discordo, e me explico.
>
> Se, por qualquer motivo que seja, você tem de misturar quantidades absurdas
> de texto com seu programa, eu posso garantir que alguma coisa está errada
> com seu projeto de software.
>
> Eu não gosto e não recomendo usar here-docs para nada: eles são
> desajeitados, menos óbvios que qualquer outro tipo de string literal, e
> permitem que a gente construa estruturas gigantescas, separando o código por
> um "mar" de texto.
>
> Bom, qual é o problema? Erros lógicos são mais complicados de pegar se você
> separa os "pedaços" e não pode olhar para todos eles ao mesmo tempo.
>
> Claro, todo mundo um dia precisou cuspir uma mensagem grande, ou um trechão
> de HTML ou Javascript, ou armazenar um "monstrinho SQL" em algum lugar. As
> minhas recomendações, em ordem de preferência:
>
>  1. Se é uma coisa recorrente, encontre um módulo que resolva o problema
> armazenando os dados em arquivos de dados (que podem ser lidos conforme a
> conveniência).
>
>  2. Se você tem apenas um texto grande, use a secção __DATA__ do seu
> programa.
>
>  3. Se você não está satisfeito com os módulos e tem mais de um texto
> grande para gerenciar, use o módulo Exporter para implementar um ou mais
> módulos (organize por alguma forma lógica e intuitiva) que exportem
> constantes com o teu texto, e lá, longe da implementação das tuas regras de
> negócio, use here-docs. Exemplo:
>
>  package My::Big::Text;
>  use strict;
>  use warnings;
>  use Exporter;
>  our ( @EXPORT_OK, @EXPORT ) = qw( $BigText );
>
>  $My::Big::Text = <<'BIG_TEXT' ;
>    bla bla bla
>  BIG_TEXT
>
>  __END__
>
> Espero que isso sirva como exemplo para duas coisas:
>
> 1. O PBP é bom, mas não está sempre 100% correto. Use seu cérebro!
> 2. Existem formas mais "complicadas" de resolver o problema de uma forma
> mais elegante. Isso é parte da filosofia básica por trás do Perl: TIMTOWTDI.
>
> Putamplexos.
> --
> Luis Motta Campos is a software engineer,
> Perl Programmer, foodie and photographer.
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>



-- 
Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com] [
www.flickr.com/photos/alexeiz]
"Though we live in trying times, we're the ones who have to try"
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20081113/9fa725ec/attachment-0001.html>


More information about the SaoPaulo-pm mailing list