A relevância da expressividade no código – Parte 1

A relevância da expressividade no código - Parte 1Olááá, leitor! Você se considera um profissional tecnicamente expressivo? Hoje trago uma discussão sobre a importância da clareza e objetividade no código-fonte, que se resumem no termo “expressividade”. Acompanhe as ideias, analogias e exemplos apresentandos neste artigo e verifique se você está sendo expressivo ao programar. Go, go, go!

 

Há algum tempo, venho citando o termo “expressividade” em alguns artigos relacionados à programação. A intenção em mencionar esse termo é ressaltar o nível de entendimento que um código bem escrito pode revelar. Mas, em detalhes, o que seria essa tal de expressividade?

Suponha que você esteja escrevendo um e-mail para o seu chefe explicando um determinado problema no módulo que você está desenvolvendo. Certamente, você tentará encontrar as melhores palavras e estruturar o texto de forma que o seu chefe não tenha dificuldades em entendê-lo, não é? Pois bem, assim como e-mails, recados, cartas, artigos, gostaríamos que outras pessoas nos entendessem sem complicações, ou melhor, queremos nos expressar ao máximo.
Sendo assim… por que não podemos fazer o mesmo com o nosso código-fonte?

Eis que lhes introduzo o conceito de expressividade no código. Como bons desenvolvedores, devemos considerar cada unidade de código como uma página de um livro, não somente pela questão da regra decrescente, mas pelo propósito em propiciar uma boa leitura.
Se você trabalha em uma empresa de desenvolvimento, outros desenvolvedores eventualmente precisam ler o seu código para realizar uma manutenção ou interpretar a regra de negócio. Neste caso, é correto afirmar que eles são os seus “leitores”. Por outro lado, se você é um desenvolvedor autônomo, é bem provável que você mesmo irá retornar ao seu código com uma certa frequência, e, convenhamos: é gratificante quando abrimos o nosso próprio código e conseguimos entender, com facilidade, o que ele faz.

 

Bom, mas nada do que eu disse fará sentido se eu não apresentar alguns exemplos.
Considere a declaração do método abaixo na classe “Clientes” de um aplicativo:

procedure Consultar;

Legal… consultar o que? Nome do cliente, contato, endereço, quantidade de compras?
Só a palavra “Consultar” não nos passa esclarecimento algum! Em primeira instância, teremos uma ideia abstrata sobre a função deste método, ou seja, saberemos que ele faz algum tipo de consulta, mas não sabemos qual. Para entender o que o método faz, será necessário verificar a sua implementação, exigindo um pouco mais de esforço. O problema é que, se a implementação do método estiver tão ruim quanto a declaração, prepare-se para passar alguns minutos interpretando as linhas de código…

Esse equívoco de utilizar um verbo genérico como nome de método é um dos fatores que motivaram a elaboração do Princípio da Menor Surpresa (ou POLAPrinciple of Least Astonishment). Este princípio visa evitar que um desenvolvedor se surpreenda com o funcionamento de um método ao utilizá-lo para um determinado comportamento, quando, na verdade, ele possui outro. Para isso, o POLA sugere a busca pela previsibilidade. Ao se deparar com a declaração ou chamada do método, o desenvolvedor já deve ter uma ideia concreta da sua ação.
Se declararmos métodos com nomes mais objetivos, mesmo que ligeiramente mais extensos, teremos uma segurança maior em utilizá-los, além de evitar o desperdício de tempo interpretando suas reais finalidades:

procedure ConsultarQuantidadeDeCompras;
procedure AbrirTelaCadastroClientes;
function VerificarSeClienteEstaCadastrado: boolean;

Ao ler as declarações acima, torna-se mais fácil compreender o que cada método realiza, ou pelo menos deveria realizar. Observe como o código fica mais legível em uma condição IF:

if VerificarSeClienteEstaCadastrado then
  ConsultarQuantidadeDeCompras
else
  AbrirTelaCadastroClientes;

Perfeito! É só bater o olho no código para identificar o fluxo da regra de negócio!
O mais interessante é que, por exemplo, o desenvolvedor pode utilizar a função “VerificarSeClienteEstaCadastrado” em qualquer ponto do software, evitando a duplicidade e concentrando a regra de negócio em apenas um local. Curiosamente, quando usamos um nome objetivo como esse, há uma tendência em memorizá-lo. Algumas vezes, já pensei: “Preciso verificar a regra de negócio X. Espere aí… acho que já existe uma função para isso!”.

 

Continuando, confira a declaração abaixo. O nível de expressividade está adequado, concorda?

procedure ConverterDocumentoPDF(const Doc: TDocumento);

Bom, eu não concordo! Pela declaração, eu não tenho certeza se o método converte o documento para PDF ou se converte um documento que é um PDF para outro formato. Mais uma vez, teríamos que gastar mais alguns minutinhos para investigar a implementação. Se, por acaso, o método estivesse declarado em uma das formas abaixo, não nos depararíamos com esse tipo de dúvida.

procedure ConverterDocumentoParaPDF(const DocumentoComum: TDocumento);
// ou
procedure ConverterDocumentoPDFParaDOC(const DocumentoPDF: TDocumento);

Atente-se que, além do próprio nome, a declaração dos parâmetros também é importante, principalmente quando se utiliza o recurso de Code Insight, no qual exibe a lista de parâmetros de um método sem a necessidade de acessar a declaração. Para que este artigo não fique muito extenso, a questão dos parâmetros será tratada na segunda parte, ok?

 

Espero vocês na semana que vem!
Abraço!


Confira as outras partes desse artigo:

A relevância da expressividade no código – Parte 1
A relevância da expressividade no código – Parte 2
A relevância da expressividade no código – Parte 3


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

5 comentários

  1. Amigo, desculpe não estar falando a respeito do topico, mas preciso de uma ajuda, se possível. Estou tentando elaborar uma rotina para envio de SMS via Delphi 7 com componentes HTTP, IdIOHandler, IdIOHandlerSocket e IdSSLOpenSSL. Meu sistema é 64bits. Está me informando uma mensagem de “could not load ssl library”. Uso o SMS da comtele que usa HTTPs. Desculpe mais uma vez, mas preciso urgente desta ajuda. Se possível, responda no meu e-mail. Um forte abraço.

  2. Salve André!
    Rapaz, já faz um tempinho que eu não visitava seu blog… Tanto que ele se tornou um site e eu nem vi!
    Gostei deste texto acerca da “expressividade”…
    Gostei, por que, como a maioria de nós, eu também gosto de encontrar argumentos para embasar meus modos de fazer algo…
    Acontece que, como não sou programador, apenas um curioso (mas já estou cuidando de fazer um curso técnico para começar), sempre que escrevo meus programinhas bestas, trato de colocar em cada função ou mesmo em cada variável um nome bem claro, para eu não me perder depois se precisar voltar e analisar o código. Além disso, eu gosto de usar comentários para me auxiliar..
    Pois bem, voltando ao ponto que citei (gosto de encontrar argumentos para embasar meus modos de fazer algo), foi muito gratificante encontrar este post, pois agora vejo que o que eu achava que era um comportamento de aspirante a programador, e que deixava meus códigos bobos com aspecto de “super amador”, são na verdade ótimas ferramentas aconselhadas para uso profissional!!
    Gostei demais de saber disso! Que ótimo que seu site existe!
    Parabéns pela nova página!
    Como sempre, continuarei acompanhando, mesmo que em intervalos nada regulares!
    Abraço, e sucesso, SEMPRE!

    1. Olá, Jadilson, quanto tempo!
      Rapaz, muito obrigado pelo seu feedback! São comentários como o seu que me motivam a continuar o trabalho no blog!
      Fico contente em saber que estou alcançando o meu objetivo de compartilhar o conhecimento!
      Jadilson, embora você ainda não tenha feito um curso de programação, eu diria, sinceramente, que você já é um programador profissional só pelo fato de produzir um código expressivo. Isso já o coloca na frente de muitos, muitos programadores formados.
      Assim como mencionei em um dos artigos, programar é uma arte. Nós, desenvolvedores, devemos assumir a nossa função de “artista” e produzir belas artes, ou melhor, códigos bem escritos. Você está nessa direção!

      Boa sorte nos estudos e na carreira profissional, meu caro!
      Obrigado novamente pelo incentivo! Abraço!

  3. Caro André, vindo de um profissional de seu gabarito só posso ficar muito contente com o elogio! Muito obrigado pela força! Abraço!

Deixe uma resposta

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

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.