Por curiosidade, comecei a me perguntar se um idioma que não permite comentários produziria um código mais legível, pois você seria forçado a escrever um código com comentários próprios.

Então, novamente, você pode escrever um código tão ruim quanto antes, porque simplesmente não se importa. Mas qual a sua opinião?

Eu acho que os programadores descobririam outra maneira de adicionar comentários ...

string aComment = "This is a kludge.";

Eu não acho tão simples assim:

mesmo em códigos bem escritos e auto-documentados, há situações legítimas em que você deve escrever comentários.

Supondo que você seja um programador perfeito (o que você não é, mas vamos supor) ...

Existem muitos efeitos não óbvios que podem acontecer no código quando você faz interface com coisas que não escreveu. Por exemplo, pode haver falhas de design na biblioteca de outra pessoa ou (se você é um desenvolvedor de kernel) no hardware de outra pessoa. Ter comentários para explicar por que você usou o kludge em particular em um determinado local pode ser essencial para entender o código e garantir que o kludge não seja removido (quebrando coisas).

É difícil para mim pensar na idéia de que a remoção de opções de um idioma melhoraria de alguma forma os programas escritos nesse idioma. Os comentários não são obrigatórios e a gravação de código auto-documentado também não é.

Não há substituto para boas práticas de desenvolvimento.

Em teoria, o COBOL foi originalmente projetado de tal maneira que deveria ser auto-documentado o suficiente para que mesmo não desenvolvedores (ou seja, supervisores) pudessem revisar o código que foi escrito e determinar o que estava acontecendo. No entanto, na prática, à medida que um programa se torna mais complexo, é difícil entender tudo o que está acontecendo exclusivamente através do código.

Ao remover comentários podem forçar alguns desenvolvedores a escrever código que é melhor em auto documentação, ainda existem desenvolvedores lá fora que escrever código mal documentado (ou seja, nomes de variáveis de a, b, c, etc) e são esses hábitos que as pessoas precisam ser treinados para fora de de. Nesses casos, a remoção de comentários não afetaria esses desenvolvedores e pode dificultar os esforços de outros desenvolvedores para explicar partes complexas do código.

Todo programa é escrito para implementar requisitos funcionais que estão fora do programa, sejam eles escritos ou apenas na cabeça de alguém.

Eu acho que a função mais essencial dos comentários é estabelecer um mapeamento entre os requisitos e o código. O motivo pelo qual o mapeamento é necessário é permitir alterações incrementais. Quando ocorre uma alteração nos requisitos, é necessário fazer as alterações correspondentes no código, para que o código permaneça uma solução para os requisitos. Os comentários servem como um roteiro para as mudanças.

Se a linguagem é uma linguagem específica de domínio (DSL) ideal, perfeitamente adaptada ao problema que está sendo resolvido, o mapeamento deve ser um isomorfismo simples e comentários não são necessários. O código-fonte simplesmente indicaria o problema e nada mais precisaria ser dito. A solução do problema estaria enterrada na implementação da linguagem.

Como os idiomas em que trabalhamos não são esses DSLs e permanecerão assim por algum tempo, ainda precisamos de comentários . É uma questão de grau. Às vezes, o problema é uma boa combinação para o idioma em questão, mas geralmente não.

Veja também...

Eu trabalho em algum lugar que não permite comentários embutidos (ou seja, você só pode ter comentários na parte superior das funções). Não, isso não facilita a leitura do código. Isso torna as ordens de magnitude piores.

Evito comentar o código e funciona.

Evito todos os comentários no código (em linha ou fluxo) em favor do docblock + variáveis ​​significativas + programação espartana , e funciona.

E sim, eu sei que os docblocks são tecnicamente comentários, ainda assim, eles são realmente complementares ao código, não intrusivos e "padronizados" ... tudo o que um comentário comum não é.

O que eu acho que poderia funcionar como um substituto dos comentários: uma linguagem / sintaxe / idioma padronizado de docblock, algo como anotações em java.

Não só isso não afetaria a qualidade - como outros observaram, seria realmente realmente irritante.

Tenho certeza de que a maioria de nós fez algo assim de tempos em tempos:

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

Quão irritante seria se você não pudesse comentar algumas linhas de código para descobrir de onde vem esse bug?

Independentemente dos comentários sobre como o código opera, coisas práticas simples como essa ou TODOanotações convenientes são coisas que facilitam a correção de pequenos problemas e lembram o que estávamos fazendo quando começamos a escrever o código.

Os comentários são como um resumo do livro. Claro, você pode entender tudo lendo o código, mas por que você quer ler uma página inteira quando pode ser resumida em uma linha comentada?

Embora eu concorde com as outras respostas de que mesmo o código de auto-documentação precisa de comentários, isso é relevante apenas para os idiomas atuais .

Penso que a verdadeira questão é: "É possível criar uma nova linguagem de programação que não precise de comentários?" Seria necessário ter um nível bastante alto com muita abstração. Cada declaração e função seria forçada a ser legível através da sintaxe da linguagem.

Programadores indisciplinados escreverão códigos ruins, não importa o idioma.

O interessante é que o python, que apenas possui convenção privada (_-prefix), não faz nenhum esforço para policiar isso, e muito código ainda está sendo escrito.

Rant: Às vezes, acho que linguagens mais permissivas forçariam mais pessoas a aprender a codificar corretamente, e não o contrário (ou seja, o Java é unidirecional e que se dane se você quiser pensar em funções como objetos de primeira classe).

Vou adivinhar: provavelmente não. Por quê? Porque você teria que codificar "por que" como um formalismo na linguagem e porque "por que", se codificado em linguagem ou em comentário em linguagem é subutilizado pelos programadores de qualquer maneira.

O código certamente pode ser um comentário para explicar o que está fazendo, mas nem sempre é possível para o código explicar por que está fazendo isso. É aí que os comentários são mais necessários.

Se, por exemplo, é necessária uma seção de código para cumprir uma regulamentação específica, como você explica isso sem comentar? Se o algoritmo usado por uma parte específica do código é descrito em um artigo escrito em 1998 por M. Matsumoto e T. Nishimura, como você explica isso sem um comentário? Se um algoritmo não fornece exatamente a funcionalidade ideal, mas faz um compromisso justificado muito específico que pode causar problemas futuros se outro código for alterado, como você o explica sem um comentário?

E se uma seção do código foi auditada por um auditor independente para que não possa ser modificada sem invalidar essa auditoria e o código é usado para criar um produto cuja conformidade com essa auditoria seja exigida pelos seus clientes. Como você indica isso sem um comentário?

Eu sempre achei que seria bom ter um comentário de uma palavra para que, se você prefixasse uma palavra com um símbolo (digamos dois pontos), essa palavra seria ignorada. Dessa forma, você poderia dizer um covarde que apenas permitia comentários de uma palavra dentro de uma expressão s. Por exemplo, você pode ativar isso:

(if (= x y)
    x
    y)

...nisso:

(if (= x y)
    :then x
    :else y)

Se for absolutamente necessário, você pode encadear vários comentários de uma palavra para formar um comentário embutido:

(if x :Remember, :x :could :be :nil!
    ...)

Claro, isso é uma dor de digitar. De fato, esse é o ponto. Ele incentiva você a usar comentários embutidos com moderação e mantê-los curtos e direto ao ponto. Mas tenho a sensação de que seria difícil convencer alguém a usar o idioma.

Isso é duplo ou nada. Alguns programadores não fazem nada para tornar o código legível. Não permitir comentários reforçará isso. Alguns programadores escrevem bons comentários, mesmo que fossem ainda melhores se fossem refatoração de código em vez de comentários - a remoção de comentários pode forçá-los a fazer a refatoração melhor.

Razões pelas quais essa é uma boa ideia: - Nenhuma

Razões pelas quais essa é uma péssima idéia: - Existem muitos programadores mais atrozes do que bons, mas não ótimos - Quase sempre deve haver alguns comentários para dicas, resumos, etc. - Mesmo que você evite comentários, provavelmente usará comentários como um palco a caminho: escreva um comentário quando estiver escrevendo algo e depois volte e refatorá-lo. Mas você nem sempre pode fazer o que é certo imediatamente, porque ainda está aprendendo. - Incentivará as pessoas a contorná-lo - Quem o usaria? Pessoas que escrevem código ilegível e querem uma desculpa (ruim) e pessoas que já estão apaixonadas pela ideia (que podem simplesmente "não escrever comentários" para começar). Se é isso que você deseja, basta escrever um padrão de codificação mostrando como você deseja que as pessoas o façam.

Razões pelas quais isso pode ser relevante - Onde poderia ser útil, é como parte de um sistema tornar "não comentar" melhor, por exemplo. uma linguagem ou IDE que tenha um bom suporte para algo melhor que comentários e como parte de seu argumento, evita comentários. Não sei como isso funcionaria, mas vale a pena pelo menos pensar nisso.