O valor da expressividade no código

27 de maio de 2010

O desenvolvedor passa muito tempo revisando e ajustando código, às vezes mais do que criando. Por isso a clareza na criação tem tanto valor. Explícito é melhor do que implícito.

A expressividade liberta.

Estamos falando do desenvolvimento de software, ciência tão complexa e fascinante quanto qualquer outra.

E que de uma forma bem grosseira e superficial podemos encarar como uma tentativa em traduzir um ambiente, procedimento ou ação do mundo real para o mundo dos bytes.

Hoje o desenvolvedor tem nas mãos uma parafernália robusta e completa para auxiliá-lo – IDEs, frameworks, metodologias e o que mais for preciso. Mas não pense que com tantos tais avanços é raro ou impossível cometer atrocidades. Ledo engano.

Como assim, Bial?

São muitos os motivos que levam projetos a falhar ou terem pedras no sapato e dores de cabeça. Hoje vamos falar apenas de um, que por parecer ridículo ou até inexistente, vem dando trabalho desde que o mundo é mundo – a falta de expressividade.

Legal, e daí?

Hoje vemos pessoas ou grupos engajadas em disseminar boas práticas e a estudar como poderemos no futuro construir software de forma ainda mais eficaz e segura.

Esse seleto grupo sempre consegue estar um passo à frente e ir além. O termo “seleto” está grifado, porque, por mais incrível que pareça, o desejo pela excelência, superação e em fazer mais e melhor não é natural a todos os profissionais ou empresas.

É uma deformação que “incha” o mercado de forma perigosa. E um dos motivos pelos quais vemos projetos em petição de miséria e causando calafrios nos envolvidos.

Um fator de destaque nestes grupos é justamente a expressividade.

O desenvolvimento é um processo interativo, pessoal ou remotamente. Em algum momento alguém vai precisar envolver-se com aquele fragmento de código que você construiu e é aí que a expressividade finalmente revela o seu valor.

“Para bom entendedor pingo é letra!”. Alto lá! Por algum motivo ainda obscuro, desenvolvedores têm fascinação por abreviações, siglas, acrônimos e afins. Não podemos generalizar, é claro, mas essa é uma prática comum.

Se um dos métodos da sua classe mais importante chamar-se processarPedidosComExecuçãoLiquida (é um exemplo, uma combinação aleatória de palavras), que assim seja; a depender do contexto (aqui suprimido) podemos acabar sendo redundantes, e é importante estarmos atentos para evitar isso – mas como neste exemplo, pressupõe-se que qualquer pessoa com entendimento mínimo sobre o negócio em si é capaz de ler e deduzir os objetivos deste método, sem ter que recorrer ao glossário, dicionário ou amigo na mesa ao lado.

Afinal poucas coisas são tão frustrantes como deparar-se com variáveis como X, var1, temp_var_cod_prod_whatever e por aí afora, às vezes usadas mais de uma vez no mesmo contexto, uma lástima!

Agregar recursos é uma outra prática comum e que dificulta severamente a suas chances de ser expressivo; existem por aí funções cujo o nome se chama Salvar, porém além de salvar, lavam, passam e servem café.

Assim fica difícil alcançar a plenitude da expressividade – faça uma coisa por vez e dê nomes (certos) aos bois!

O que mais se aproxima do caminho das pedras: como em tudo nessa vida não existem regras, fórmulas perfeitas para o sucesso. Existe bom senso e é ele que deverá guiá-lo rumo a excelência.

Abaixo alguns trechos do texto The Zen of Python para encerrarmos o assunto.

Legibilidade conta

“Ao encarar a ambiguidade, recuse a tentação de adivinhar.
Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de se fazer isto.”

“Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.”

O texto completo é uma leitura interessante e recomendada, vale tanto para o desenvolvimento de software quanto para a vida!

Resultados práticos

Dizem as más línguas que se passa mais tempo revisando e ajustando código do que propriamente criando. Isso sendo verdade (alguém tem o o link?) a importância da expressividade é elevada a um valor astronômico.

E agora mais uma citação da melhor linguagem de programação do planeta (até hoje pelo menos) que define tudo: explícito é melhor do que implícito. [Webinsider]

…………………………

Conheça os planos de hospedagem da HostLayer.

Acompanhe o Webinsider no Twitter.

Avalie este artigo:
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

5 respostas para “O valor da expressividade no código”

  1. Felipe Couto disse:

    Excelente artigo.

    Realmente expressividade no código é fundamental. Concordo com o que o Vinicius Assef disse, “É muito melhor um código claro do que um todo comentado”.

    Onde trabalho não tem um nem outro, é muito complicado, nome de variável tudo abreviado, nome de funções, pior de tudo é a base de dados, se tivessem escolhido um nome mais ‘amigável’ seria mais natural o entendimento do código e de toda a aplicação em si…

  2. Tweets that mention » O valor da expressividade no código Webinsider -- Topsy.com disse:

    […] This post was mentioned on Twitter by Julio Valentim, Vicente Tardin, Blog Mídia8!, Chico Eugenio, Diego Oliveira and others. Diego Oliveira said: O valor da expressividade no código http://webinsider.uol.com.br/2010/05/27/o-valor-da-expressividade-no-codigo/ […]

  3. Rodrigo Braga disse:

    Assef

    Excelente link!

    Nogueira

    “Espalhar essa idéia” é a nossa missão 🙂

  4. Beto Nogueira disse:

    Muito pertinente, clareza no código ajuda muito nas tarefas triviais e com certeza escrever um bom português ajuda nessa hora.
    A criatividade e o bom senso tem que caminhar juntos, quem quiser espalhar essa idéia é bem vindo, temo pelos que ficam indiferentes.
    Abraços!

  5. Segue o link sobre viver dando manutenção em código: http://www.artima.com/intv/dry.html

    Expressividade é fundamental. É muito melhor um código claro do que um todo comentado. Se precisa comentár, normalmente não está bem feito (leia simples) o suficiente.

    Entretanto, sou favorável a nomes de variáveis curtas, quando o contexto permite. Por exemplo, é melhor ter um loop de indexacao usando “i” do que “indice”, por exemplo.

    Para bom entendedor, pingo é pingo mesmo! Se alguém entender seu pingo como letra, tem coisa errada. Normalmente com seu código.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *