Por que não ambos?
Primeiro de tudo, "descritivo" e "detalhado" não são os mesmos. Por exemplo, se você estiver escrevendo um loop local, ié um nome de variável muito bom para a variável de loop; current_iteration_index, embora indiscutivelmente mais descritivo e definitivamente mais detalhado, é muito pior e não adiciona nenhuma informação, porque o uso de icomo variável de loop é praticamente universalmente aceito e não há outro significado para iisso.
Bons nomes de variáveis são descritivos, pois um programador familiarizado com o idioma da linguagem e com as convenções da base de código pode adivinhar com facilidade qual é seu papel, mas também é conciso o suficiente para manter as coisas compactas.
O limite de 80 caracteres, apesar de originalmente ser uma conseqüência das limitações técnicas dos terminais de texto dos anos 70, ainda é valorizado por muitos atualmente, e mesmo que ainda haja razões técnicas (comprimentos máximos de linha em alguns protocolos de rede, principalmente os relacionados a email), as razões mais convincentes são psicológicas e sociais. Acontece que comprimentos de linha em torno da marca de 66 caracteres proporcionam a experiência de leitura mais confortável para a prosa em linguagem natural (o tamanho da fonte interessante não faz muita diferença e, consequentemente, o tamanho da tela ou do papel); Os limites de linha de 80 caracteres são muito próximos disso, mas como a maior parte de um pedaço de código típico geralmente é recuado em pelo menos um ou dois níveis (o que significa entre 4 e 16 caracteres, dependendo das configurações de recuo),
Outro efeito de seguir as linhas de 80 caracteres é que é um bom indicador de quando as coisas são muito complicadas. As linhas longas são geralmente causadas por um dos seguintes:
- Funções com uma longa lista de argumentos; isso não é uma coisa agradável de se ter, porque eles impedem a legibilidade e podem facilmente causar erros sutis, por exemplo, quando as pessoas trocam a ordem dos argumentos de uma maneira que o compilador não pega.
- Expressões complexas, freqüentemente encontradas em condicionais (por exemplo
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); isso também costuma ser bastante difícil de decifrar, e o código deve ser reescrito em algo mais estruturado. Muito provavelmente, a expressão faz muito e deve ser fatorada em um método ou função.
- Literais longos usados em chamadas ou expressões de função, por exemplo
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Mova o literal para uma variável ou constante; ele ainda pode exceder o comprimento da linha, mas se você fizer isso de forma consistente, o leitor poderá pelo menos ignorar com segurança a parte invisível da linha, assumindo que apenas o restante do literal se segue. Ou, melhor ainda, mova os literais para fora do código e entre em um armazenamento de dados externo (arquivo, banco de dados, qualquer que seja).
- Instruções profundamente aninhadas, por exemplo, seis níveis de
ifinstruções em um método de classe (são 32 colunas de recuo para configurações típicas). Novamente, o aninhamento profundo cria um código complexo e de difícil leitura, e deve ser evitado como uma praga - simplificando, o aninhamento profundo transborda a pilha do cérebro humano durante a leitura.
No final, todos esses são sintomas de coisas que você preferiria não ter em sua base de códigos, e impor limites de 80 caracteres é uma maneira simples e agradável que ajuda a manter a complexidade e a legibilidade reduzidas. (Isso não quer dizer que você não pode escrever código perfeitamente ilegível em 80 colunas: os vários concursos de código ofuscado são um contra-exemplo claro).