Nesse meu exemplo o codigo vai ser usado por pessoas que não falam portugues e a lingua comum é o inglês (eles falam francês).
Alias se vc for liberar um modulo no CPAN é muito interessante vc escolher uma lingua como o inglês por assim vai atender a muitas pessoas de diferentes paises. O que não impede de documentar em outros idiomas como o pt_BR se for necessario. 2014-02-27 11:20 GMT-03:00 Ricardo Stock <ricardost...@bol.com.br>: > Ola Tiago. > > Veja eu concordo com voce no que diz a metodos do tipo "obscuros" até > mesmo classes, variaveis ou funções ou mesmo condicionais que ninguem > entende até mesmo quem fez depois de um certo tempo. > > Aquela massima de que "quem vai manter seu codigo é um serial killer e tem > seu endereço é verdade". só uma coisa que não concordo e que vejo em muitas > pessoas que estão na lista. > > Porque comentar, explicar, escrever em ingles se nossa lingua e portugues > e temos uma deficiencia enorne de material tecnico de qualidade em lossa > lingua. Em meus códigos, eu SEMPRE documento, comento em portugues. > > > Está é só a minha opnião... Sem flames. > > Ricardo Stock > http://www.stocksistemas.com.br > > *From:* Tiago Peczenyj <tiago.pecze...@gmail.com> > *Sent:* Thursday, February 27, 2014 10:12 AM > *To:* saopaulo...@mail.pm.org > *Subject:* Re: [SP-pm]Perl write-only, que comece o flame [WAS Perl e > horário de verão] > > Existe o problema das culturas. > > Se eu não sei programar, o que eu usar, seja C, Haskell ou Perl, vai sair > esquisito. Talvez funcione. Talvez resolva o meu problema. A questão é que > a linguagem evolui assim como a sua comunidade. Hoje tem uma parte da > comunidade que defende boas praticas, que defende testes, que defende um > codigo legivel. > > Recentemente eu trabalhei num projeto Ruby ( > https://github.com/peczenyj/MooseX ) e vou dizer, eu consigo produzir um > codigo talvez até mais legivel em Ruby do que em Perl. Porém vc tem casos > onde a galera abusa do fato da linguagem possuir classes abertas e não raro > alguem injeta 500 metodos sem vc saber em alguma classe tipo Object ou > String. Eis o problema da cultura: não é só pq eu posso que eu devo fazer. > Existem praticas para produzir algo que seja usavel por um grupo maior de > pessoas e que seja possivel dar manutenção num futuro proximo. > > Estou trabalhando em Perl 5.12.2 e usando Moo. Eu tento usar nomes > legiveis para as minhas variaveis, eu tento adicionar comentarios / pod > quando preciso fazer algo obscuro > > por exemplo: > > sub _generate_random_foo { > my ($thing) = @_; > > # to generate random foo based on the thing: > # 1 - sha1_hex of thing, to generate a hexadecimal hash > # 2 - pick two first hexdigits (returns 0x00 <= x <= 0xff) > # 3 - convert from hex to decimal (returns 0 <= x <= 255) > # 4 - apply 100 * value / 256 to rescale between 0 <= x < 100 > # 5 - truncate to integer > # 6 - abs returns a positive integer or zero > # 7 - modulus 100 will ensure it will return something less than 100 > # we will return a number between zero and 99 > > abs( int( 100 * hex( substr( sha1_hex($thing), 0, 2 ) ) / 0x100 ) ) % > 100; > } > > os dois ultimos passos eu adicionei de paranoia depois que acharam "coisas > estranhas acontecendo". > > qual o limite para isso ser legivel ou não? um bom processo de code > review. Se eu simplesmente remover os comentarios alguem vai perder 20 > minutos no futuro tentando entender essa porra. > > Eu fui programar em Java semana passada. Cara que dificuldade que é fazer > um simples join ",", @array ! Eu preciso usar uma biblioteca externa pra > fazer isso. E adicionar uma biblioteca externa significa depender de maven > ( ou graddle) pra fazer alguma coisa que eu queria que tivesse 0 > dependencias externas. No fim eu posso criar uma classe "Util" que vai ter > esse tipo de coisa. E Javadoc. Ou posso socar um foreach + StringBuilder no > meio da minha logica e ficar com um metodo de 75 linhas no fim das contas. > A minha dificuldade? estou fazendo sozinho, ninguem pra revisar ou criticar > o meu codigo. > > Existem formas de analisar o codigo ( dependendo da linguagem ) e achar > problemas, metodos muito complexos, problemas de cobertura de teste, etc. > Esse tipo de ferramenta ajuda (E MUITO) mas não faz o trabalho humano. > > 2014-02-27 9:55 GMT-03:00 Blabos de Blebe <bla...@gmail.com>: > >> Pra quem for continuar no assunto, seguem apenas umas considerações >> menores e de pouca importância: >> >> https://metacpan.org/pod/Devel::Cover >> https://metacpan.org/pod/Perl::Critic >> https://metacpan.org/pod/Perl::Tidy >> https://metacpan.org/pod/Test::Most >> >> Algo ainda mais irrelevante: >> >> https://metacpan.org/pod/Catalyst >> https://metacpan.org/pod/Mojolicious (pra focar num flame de cada vez) >> https://metacpan.org/pod/DBIx::Class >> https://metacpan.org/pod/Template >> >> Eu to falando irrelevante, não pelos módulos em si, mas pela minha >> abordagem na resposta. Eu não vou nem usar argumentos mais sólidos que isso. >> >> Agora, criatura das neves, se com pelo menos isso, você ( um você >> genérico, ninguém pessoalmente ok!? ) ainda acredita em Perl write-only, >> Papai Noel ou no Pé Grande, nada pessoal, mas não me venha dizer que você é >> o experiente grande programador foda do alto da montanha, porque, desculpa, >> você não é. >> >> Se com todos esses frameworks de apoio ( pra citar o mínimo ) você ainda >> escreve código tosco, **você** é o tosco, não a linguagem. >> >> Um código é tão ruim quanto a competência do infeliz que o escreveu, e >> não por causa da linguagem. >> >> Existe Perl tosco? Sim. Existe. Tem coisas que eu diria que é Shell >> Script com shebang perl. >> >> Mas se em 2014 você usa perl-5.18.2 pra escrever lixo, você é o tosco. E >> se em 2014 você ainda propaga essa ladainha, desculpa cara, sai dos anos 90 >> e vem viver no presente. >> >> Eu não sou tão velho assim, mas com 15 anos de mercado, já trabalhei com >> algumas coisas (e ambientes) bem bizarras e posso garantir que não só em >> Perl, mas em PHP, Java, C, .NET e coisinhas da moda (só pra citar as que eu >> já trabalhei), dá pra achar coisas que vão te fazer sentir vontade de parir >> a própria mãe só pra matar ela no berço por ter te criado e educado ao >> ponto de vc ser obrigado a ver certos códigos. É triste. >> >> Por que a linguagem é write-only? Não, criatura, por que quem escreveu é >> um imbecil. >> >> Assim como existem pedreiros ruins, médicos ruins, professores ruins, >> surpresa, supressa, oh, existem programadores ruins! Nossa! >> >> Eu não vou nem entrar no mérito do gestor que te proíbe de refatorar >> aquele código legado porque "mexer em código que está funcionando é >> desperdício". Pra esse já me faltam adjetivos, talvez eu devesse aprender >> klingon. >> >> E só pra deixar claro aqui, eu to criticando, o cara que hoje, faz coisa >> tosca sabendo que é tosco e dá a desculpa esfarrapada de que é culpa da >> linguagem. >> >> A existência de um legado, que foi construído dentro de um contexto >> particular, embora questionável, é outro papo. Muito embora eu já tenha >> pegado muito código legado do século passado, que é bem melhor escrito que >> os de hoje. >> >> []'s >> >> >> >> >> 2014-02-27 8:27 GMT-03:00 Alceu Rodrigues de Freitas Junior < >> glasswal...@yahoo.com.br>: >> >>> Em 27-02-2014 01 <27-02-2014%2001>:05, Blabos de Blebe escreveu: >>> >>> A concepção de programadores experientes sobre Perl, pelo menos por >>>>> onde passei, é > que Perl ainda é linguagem "write-only" >>>>> >>>> >>>> Não tão experientes pelo visto... >>>> >>>> Mas isso é só um comentário pessoal e não agrega nada à thread que >>>> aliás, WTF o que eu to fazendo!? Passou, passou, passou... >>>> >>>> >>> Pelo contrário, faz parte do problema conforme descrito pelo Geraldo. >>> Acho totalmente válido seu comentário, apesar de não ajudar muito. :-) >>> >>> É difícil desfazer preconceitos e geralmente leva tempo... algumas vezes >>> eu acho que nem vale a pena tentar. >>> >>> >>> Talvez seja uma boa realizar o trabalho sujo numa outra máquina, >>>> produzir os comandos de shell e enviá-los pra esse servidor via ssh ou >>>> algo parecido. >>>> >>> >>> Concordo. Ele só precisar saber o horário de verão, e se usar Perl é um >>> "problema" porque ninguém conhece, pode usar shell script mesmo, comparar >>> $TZ para saber que época do ano está e usar ssh/telnet para executar o >>> programa do HP Open View lá no True64, já com o valor de timezone. >>> >>> []'s >>> Alceu >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>> =end disclaimer >>> >> >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> >> > > > -- > Tiago B. Peczenyj > Linux User #405772 > > http://about.me/peczenyj > > ------------------------------ > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > -- Tiago B. Peczenyj Linux User #405772 http://about.me/peczenyj
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer