Nesta semana está acontecendo a Rubyconf 2008 e uma das palestras que me chamou a atenção é a de Michael Granger que tratará sobre como deixar seu código Ruby mais legível, comunicativo e mais fácil de se manter. Para tal ele irá aplicar o príncipio de design visual de Robin Williams conhecido como CRAP (sigla para Contraste, Repetição, Alinhamento e Proximidade). Para quem não entende inglês, o significado da palava “crap” é lixo, porcaria. Além disso ele usará algumas idéias do método de programação espartano (Spartan Programming), Michael Schwern, Marcel Molina Jr. e do grande mestre dos computeiros, Donald Knuth.

Pois, justamente, semana passada assisti uma das palestras da Rubyconf 2007 no site da Confreaks (espero que as palestras da Rubyconf 2008 também estejam lá). Era a palestra de Marcel Molina Jr. e ele falava sobre o que faz um código belo. Esta palestra também foi uma keynote na Ruby Hoedown 2007. Tentarei apresentar aqui sua essência.

Marcel disse que não faria uma apresentação acadêmica. Afirmou que, ao pensamos em beleza, geralmente pensamos em aparência e nos vem a imagem de um bebê, uma mulher ou uma flor. Mas essa definição é muito superficial.

Software belo é a mesma coisa que um bom software. Como já dizia o pensador francês Jean-Jacques Rousseau. “Bom nada mais é que a beleza em ação e ambos tem uma fonte comum na natureza organizada”.

O conceito de natureza organizada é explicado por Pitágoras, que conhecemos no segundo grau, nas aulas de geometria. Ele dizia que a beleza vem dos números, eles estão em toda a parte. “Todas as coisas existem por serem ordenadas. E elas são ordenadas porque são a realização de leis matemáticas”. Pitágoras ouviu a beleza de som que vinha dos martelos de um ferreiro, uma verdadeira melodia. Então observou que existia uma proporção entre os diferentes tamanhos de martelo. Este conceito de proporcionalidade também foi usado nas construções arquitetônicas da Grécia antiga.

Contudo foi a definição de São Tomas de Aquino aquela que o palestrante explorou com maior profundidade e que ele acredita que melhor se encaixa com software. Para o sábio teólogo a beleza é definida por três regras:

1. a proporção, isto é, apresentar uma boa estrutura em que a relação de tamanho entre as diferentes partes do objeto seja proporcional, mantendo o tamanho o menor possível.

2. a integridade, isto é, o objeto deve servir para o propósito em questão. Ele exemplifica falando do martelo de cristal: tem beleza física, mas não tem integridade pois não é uma boa solução para o problema de bater pregos, já que se quebraria em diversos partes se fosse usado para tal propósito.

3. a clareza, isto é, o objeto deve ser simples/claro. Vide os designs desenvolvidos pela Apple.

Em seguida, Marcel dá um exemplo para mostrar como estes três conceitos se aplicam a código. O programa usado como exemplo deve converter strings de um arquivo XML para tipos correspondentes (fazer a coerção) em Ruby:

"true"      =>  true
"false"     =>  false
"42"        =>  42

Ele então chegou a seguinte implementação:

class CoercibleString < String
  attr_accessor :generator
  def coerce
    attempt = nil
    break unless (attemp = coercions.next).nil? while coercions.next?
    attempt.nil? ? self : attempt
  end

  private
    def coercions
      Generator.new do |self.generator|
        try { self  == 'true'         }
        try { [self == 'false', false]}
        try { Integer(self)           }
        try { Date.parse(self)        }
       end
    end

    def try
      attempt, desired = yield
      generator.yield(desired.nil? ? attempt : desired) if attempt
      rescue ArgumentError
        generator.yield nil
      end
    end
end

Ele mostra também a implementação final do programa:

Class String
  def self.coerce(string)
    case string
    when 'true' :          true
    when 'false' :         false
    when /^[1-9]+\d*$/ :   Integer(string)
    when DATETIME_FORMAT:  Time.parse(string)
    else
      string
    end
  end
end

Marcel explica brevemente o funcionamento da solução e então avalia a beleza da primeira implementação.

• Proporcionalidade: em relação as partes do código (métodos) são mais ou menos proporcionais. Porém, se formos olhar a quantidade de código, é realmente necessário tanto código para resolver o problema? A segunda solução tem metade do tamanho, portanto a proporcionalidade da primeira solução é bem ruim.

• Integridade: No Ruby 1.9 os generators (usados pela primeira solução) são implementados com threads, mas no Ruby 1.8 eles usam continuations, o que é bastante lento. Mudando para a segunda implementação os testes de Marcel rodaram uma ordem de magnitude mais rápidos em relação a primeira. Ou seja, falhamos também na integridade.

• Claridade: Marcel diz que teve que explicar o funcionamento do primeiro código e diz saber que ele não é claro. Já o segundo é bem mais claro (alguém tem dúvidas disso?).

Inicialmente, ele não sabia que o código era ruim. Marcel pensou que poderia ser um jeito novo, interessante de se resolver o problema de coerção. Mas, no final das contas, mostrou-se não ser um belo código.

Então ele afirma: Você não escolhe um ou dois princípios. Os três são necessários e nenhum deles é suficiente.

Por exemplo, não se deve sacrificar a clareza em prol da proporcionalidade, isto é, criar códigos curtos que são incompreensíveis.

Você pode me explicar o que fazem os códigos a seguir? Bem, deixa pra lá.

expand(join("",(map { /\s+\z/ ? ( $_ ) : ($_, ' ') } @t), $tail));

foreach (@ARGV) {
 /(\.[^.]+)$/ && $exten{$1}++ foreach glob "$_/*.*"
}

O palestrante então nos introduz ao livro Smalltalk Best Practices Patterns de Kent Beck (sim, o mesmo cara por trás do XP). Neste livro dos anos 80, o autor trabalha com a linguagem Smalltalk e dá algumas dicas de como desenvolver software de melhor qualidade;

Ele então cita algumas frases do livro:

• “Este padrão enfatiza a legibilidade.”
• “Métodos de uma linha estão lá para comunicar-se.”
• “Objetos são mais fáceis de se gerenciar se são divididos em pequenas partes.”
• “A maioria dos bons métodos escritos em Smalltalk cabem em umas poucas linhas.”
• “Você não gasta três ou quatro linhas para expressar iteração, você gasta uma palavra.”
• “O problema de um código como este é que você não pode lê-lo e entender o que se passa”.

E estas frases nada mais fazem que afirmar os três conceitos de beleza de São Tomás de Aquino.

Marcel nos pergunta, como tudo isso dito aqui é útil?

Bem, o código da segunda implementação que taxamos como belo não tem nada de especial. Mas, a 40 anos atrás isso era fantástico, inovador. Imagine trabalhar com assembly e ter a funcionalidade do switch (case). Mas agora, Ruby é o jeito mais belo de se escrever software nos últimos 20 anos embora ele pareça simples. É um alvo em movimento.

John McCarthy, o criador da linguagem Lisp (ele apenas especificou a linguagem, não a implementou) introduziu o conceito de if_” na programação. Você consegue imaginar programação sem o _if? As pessoas trabalhavam sem ele. Mas, quando introduzido, o _if_ deve ter sido um belo conceito.

E aqui vai uma frase interessante de Niels Bohr. “Um especialista é uma pessoa que cometeu todos erros que poderia ter feito num campo bem restrito”.

Assim Marcel fala que sua implementação inicial de coerção foi um erro. Assim como, quem inicialmente introduziu o switch poderia ter optado por uma implementação padrão na época.

Mas ele tentava fazer algo diferente que fosse melhor. E no final, em relação a beleza, o código era ruim.

Ruby é otimizada para beleza. O que Marcel tenta chegar com isso é, que quando trabalhando com software:

• tente imaginar melhores modos de expressão
• violações das três regras da beleza revelam erros - se você perceber que está violando as regras tente fazer ajustes ou reescreva o código
• se você fizer isto suficientemente você pode terminar por obter algo inovador e belo

Esta é uma simples abordagem que Marcel tem usado e que ele acredita que tem sido um sucesso devido ao bom retorno que tem recebido. O palestrante finaliza agradecendo ao Matz e ao Ruby Core Team por terem criado Ruby, que, na sua opinião, é a linguagem de programação mais bela em uso.

Espero que este texto tenha sido útil, apesar de eu ter violado as regras de beleza!

Assim que eu tiver alguma informação da palestra de Michael Granger na Rubyconf 2008, tratarei sobre ela aqui.