1) eu nao advoguei em nenhum momento no texto o NÃO uso de nomes claros e explicitos em funções, variáveis e estruturas de dados. Pode procurar, eu tenho certeza disse. Eu faei da vantagem de ter EXPRESSÔES COMPATCTAS, com grande poder. Eu DETESTO funçoes com nomes do tipo fddq, ou variáveis c, h e a (a menos que sejam temporarias e bem localizadas).

2) Eu tampouco critiquei a funcionalidade do Eclipse de varrer código. Acho isso muito útil e uso demais. EU critiquei estruturas extremamente complexas (em geral criadas em nome de uma certa escalabilidade) que fazem com que qualquer código tenha no mínimo dois níveis de indireção.

Miguel, mesmo assim ainda prefiro esse estilo de varreduras de classes e métodos no Eclipse, pois às vezes bater o olho na especificação do método (aka contrato) já me basta, se eu estiver interessado apenas no “o que” o método faz e não “como”.

Com relação à questão de “quanto mais treinado, mais legível o código”, ainda assim prefiro ter um método ou função com um nome legível informando a responsabilidade da operação, do que poucas invocações compactas que retornem booleanos e determinem resultados de validações / verificações. Na tarefa de simples “bater o olho”, é rápido de se afirmar o que faz determinado método. Por exemplo, eu prefiro muito mais um isCreditCardAuthorized() do que linhas dispersas retornando booleanos que resumem esta operação. A manutenção se torna em muito facilitada.

Raphael, Primeiro, o nome ClassPathXmlApplicationContext é um token só.

O funcionamento interno de um container (como por exemplo o do Spring) em nada está relacionado com uma conversa sobre a sintaxe de uma linguagem ou certo estilo de programação ser verborrágico ou não, compreende a diferença?

Em meio profissional procuro escrever da maneira mais legível possivel, mesmo que resulte em nomes de classes a lá Spring como ClassPathXmlApplicationContext.

Em quantos lugares diferentes passam declarações de classes, arquivos XML para fluxo do programa, configuração e instanciação e etc? Vários. Redundância “extreme”.

Raphael, um if retornar algum dos operandos da expressão booleana está anos luz longe da linguagem “humana”.

“Mais idéias em menos código” nem sempre leva a uma perda de legibilidade, me vem em mente agora os operadores para “fatiar” strings de Ruby por exemplo, onde o código fica menor e ainda sim fácil de ler.

Mas muitos estilos de codificação mais compactos levam sim a uma perda enorme de legibilidade do código lhe forçando a gastar muitas vezes mais tempo para ler uma linha que de outra maneira poderia ser compreendida apenas “batendo o olho”. E lembrando que no nosso dia a dia nós lemos milhares de linhas de código e mtas vezes estamos em condições de stress onde pequenos detalhes “escapam” para o ambiente de produção impunemente, graças mtas vezes a erros de leitura…

O estilo que eu defendo de maneira alguma promove a redundãncia de tokens, baseado em que você assumiu isto??? Algum exemplo que eu citei aqui???

Acho que hoje em dia os desenvolvedores se preocupam muito com arquiteturas de classes, heranças, patterns e afins, e se preocupam muito pouco com a qualidade do código que vai dentro dos métodos.

E é fato que uma expressão do tipo (v AND 1) or 2 pode ser bem dificil de entender a primeira vista. Mas não é mais dificil do que tentar entender um método que chama um façade que chama um proxy que chama uma interface cuja implementação é injetada por uma lib cuja definição está num XML perdido em algum lugar da arvores de arquivos de properties do sistema. Que jogue uma pedra aquele que nunca passou alguns minutos apertando Ctrl Mouse no Eclipse para tentar encontrar onde raios estava a implementação de um método.

Mas isto é assunto prum outro post….

eu acho que existe algo que tem que ser levado em conta nisso tudo: bom senso. Eu já devo ter dito isso em algum lugar neste blog, mas vale a pena ressaltar: eu tenho cada vez mais certeza de que escrever código é uma arte. Muito semelhante a escrever texto. Quando escrevemos um texto, o estilo depende muito da finalidade. As vezes queremos um texto mais direto, seco. Outras vezes, um texto mais poético. As vezes mais cínico. O mesmo vale pra código: as vezes queremos um código mais enxuto, as vezes queremos um código mais explícito e óbvio. Mas eu acredito que é importante que desenvolvedores fiquem sempre atentos a novas formas de efetuar certas tarefas, novos recursos…..é importante ter o maior número de ferramentas na nossa caixinha de maldades. As expressões booleanas que eu mencionei no texto são algumas destas ferramentas.

Quanto à questão da legibilidade, eu mantenho o que eu disse antes: quanto mais treinado for o olho, mais legível será o código. E sinceramente, acho que a qualidade não deve ser nivelada pelo nível do pior programador da equipe. Pelo contrário: quanto maior o nível do código, maior vai ser o progresso dos membros.

E vale ressaltar que a quantidade de código medíocre por aí, feito sem nenhum tipo de interesse ou cuidado, é enorme. Não que eu ache que os meus códigos sejam geniais. Pelo contrário. Mas eu tenho uma autocrítica extremamente alta, e tento o tempo todo descobrir coisas novas e melhorar.

[]s

Eu, particularmente, sou um fã moderado de estruturas que compactam o código. Acho que muitas vezes elas servem apenas para diminuir a legibilidade do código.

Por exemplo, para mim, o seu primeiro exemplo é fantástico e simples! Já o segundo é relativamente sofrível de entender, na minha opinião. Principalmente se você nunca viu um código, está tentando entendê-lo pela primeira vez e não tem muito tempo para isso. Algo que recorrentemente acontece durante um ciclo de desenvolvimento.

Coincidentemente estou tendo uma discussão muito parecida com esta no meu trabalho nos últimos tempos. O engraçado é que, como já escrevi aqui algumas outras vezes, todo o meu desenvolvimento é de plug-ins para Eclipse, ou seja, Java. Java, como C, tem algumas construções de código que podem torná-lo menor mas que por outro lado, podem torná-lo mais ilegível também. Resta saber qual é esta linha entre compacto/ilegível para a sua equipe de desenvolvimento.

No nosso caso estamos usando o próprio Eclipse para definir os padrões que queremos seguir. O IDE permite que você selecione níveis de avisos para construções sintáticas que, apesar de não estarem erradas pela especificação da linguagem, podem causar confusão para um leitor desavisado ou mesmo bugs por desatenção do programador. Um exemplo clássico sob o qual é possível setar o nível de aviso é o uso de “switch case fall-through”, ou seja, quando você dentro de um case de um switch não utiliza um break e força a continuação da execução do código do próximo case para o case anterior também. Apesar de permitido pela linguagem, isso pode causar confusão para um leitor desavisado do seu código e, pior, pode ser uma fonte de bugs já que na maior parte das vezes você vai querer colocar um break em cada case do seu switch.

Enfim, como eu disse antes, algo que eu acho que deve ser usado com cuidado. Muito cuidado. E com o consentimento de sua equipe de desenvolvimento como um todo.

Agora… se estivermos falando de código próprio… Bom, eu uso e abuso de compactações de código. Afinal, eu acho que é uma ótima oportunidade de aprender e só eu mesmo vou ler o que eu estou fazendo.

Se uma linguagem oferece uma construção com uma abstração maior (mais próxima da “linguagem humana” do que da “linguagem da máquina”) e se essa mesma construção permite que você tenha uma capacidade maior de expressar idéias em menos código, como é que você acaba por argumentar que um estilo que promove verbosidade e redundância de tokens ajuda na legibilidade?