Par simple curiosité, j'ai commencé à me demander si un langage qui n'autorise pas les commentaires produirait un code plus lisible car vous auriez été obligé d'écrire du code auto-commenté.

Là encore, vous pourriez écrire du code aussi mauvais qu'avant parce que vous ne vous en souciez pas. Mais quelle est votre opinion?

Je pense que les programmeurs trouveraient une autre façon d'ajouter des commentaires ...

string aComment = "This is a kludge.";

Je ne pense pas que ce soit aussi simple:

même dans un code bien rédigé et auto-documenté, il existe des situations légitimes où vous devez écrire des commentaires.

Supposons que vous soyez un programmeur parfait (ce que vous n'êtes pas, mais supposons simplement) ...

Il y a beaucoup d'effets non évidents qui peuvent se produire dans le code lorsque vous vous connectez à des choses que vous n'avez pas écrites. Par exemple, il peut y avoir des défauts de conception dans la bibliothèque de quelqu'un d'autre ou (si vous êtes développeur de noyau) dans le matériel de quelqu'un d'autre. Avoir des commentaires pour expliquer pourquoi vous avez utilisé un kludge particulier à un endroit particulier peut être essentiel pour comprendre le code et vous assurer que le kludge n'est pas supprimé (casser des choses).

Il est difficile pour moi de résumer mon idée que la suppression d'options d'une langue améliorerait en quelque sorte les programmes écrits dans cette langue. Les commentaires ne sont pas obligatoires et l'écriture de code auto-documenté ne l'est pas aussi.

Rien ne remplace les bonnes pratiques de développement.

En théorie, COBOL a été conçu à l'origine de telle manière qu'il était censé être suffisamment documenté pour que même les non-développeurs (c'est-à-dire les superviseurs) puissent examiner le code écrit et déterminer ce qui se passait. Cependant, dans la pratique, à mesure qu'un programme devient plus complexe, il est difficile de comprendre tout ce qui se passe uniquement via le code.

Lors du retrait de commentaires pourrait forcer certains développeurs à écrire du code qui est mieux à la documentation de soi - même, il y a encore des développeurs là - bas qui écriture de code mal documenté (c. -à -noms de variables a, b, c, etc.) et ce sont ces habitudes que les gens doivent être formés sur de de. Dans ces cas, la suppression des commentaires n'affecterait pas ces développeurs et pourrait entraver les efforts d'autres développeurs pour expliquer des morceaux de code complexes.

Chaque programme est écrit pour implémenter des exigences fonctionnelles qui sont en dehors du programme, qu'elles soient écrites ou simplement dans la tête de quelqu'un.

Je pense que la fonction la plus essentielle des commentaires est d'établir une correspondance entre les exigences et le code. La raison pour laquelle le mappage est nécessaire est de permettre des modifications incrémentielles. Lorsqu'une modification des exigences se produit, il est nécessaire d'apporter des modifications correspondantes au code, si le code doit rester une solution aux exigences. Les commentaires servent de feuille de route pour les changements.

Si la langue est une langue de domaine spécifique (DSL) idéale parfaitement adaptée au problème résolu, la cartographie devrait être un simple isomorphisme et aucun commentaire ne serait nécessaire. Le code source énoncerait simplement le problème, et rien d'autre n'aurait besoin d'être dit. La solution du problème serait enterrée dans la mise en œuvre de la langue.

Étant donné que les langues dans lesquelles nous travaillons ne sont pas de telles DSL et le resteront pendant un certain temps, nous avons encore besoin de commentaires . C'est une question de degré. Parfois, le problème correspond bien à la langue utilisée, mais généralement pas.

Voir également...

Je travaille quelque part qui ne permet pas les commentaires en ligne (c'est-à-dire que vous ne pouvez avoir que des commentaires en haut des fonctions). Non, cela ne facilite pas la lecture du code. Cela aggrave les ordres de grandeur.

J'évite de commenter le code, et cela fonctionne.

J'évite tous les commentaires dans le code (en ligne ou en flux) en faveur de docblock + variables significatifs + programmation spartiate , et cela fonctionne.

Et oui, je sais que les docblocks sont techniquement des commentaires, quand même, ils sont en fait complémentaires au code, pas intrusifs et "standardisés" ... tout ce qu'un commentaire commun n'est pas.

Ce que je pense pourrait fonctionner comme un substitut de commentaires: un langage / syntaxe / idiome docblock standardisé, quelque chose comme des annotations en java.

Non seulement cela n'affecterait pas la qualité - comme d'autres l'ont observé, ce serait en fait vraiment ennuyeux.

Je suis sûr que la plupart d'entre nous ont fait quelque chose comme ça de temps en temps:

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

À quel point serait-ce irritant si vous ne pouviez pas commenter quelques lignes de code pour comprendre d'où vient ce bogue?

Indépendamment des commentaires sur le fonctionnement du code, des choses pratiques simples comme celle-ci ou la suppression d'une TODOnote pratique sont des choses qui facilitent la résolution des problèmes mineurs et se souviennent de ce que nous faisions lorsque nous avons commencé à écrire le code.

Les commentaires sont comme un résumé de livre. Bien sûr, vous pouvez tout comprendre en lisant du code, mais pourquoi diable voulez-vous lire une page entière alors qu'elle pourrait être résumée en une ligne commentée?

Bien que je sois d'accord avec les autres réponses selon lesquelles même le code auto-documenté nécessite des commentaires, cela ne concerne que les langues actuelles .

Je pense que la vraie question est: "Est-il possible de concevoir un nouveau langage de programmation qui n'a pas besoin de commentaires?" Il faudrait que ce soit un niveau assez élevé avec beaucoup d'abstraction. Chaque instruction et fonction serait forcée d'être lisible via la syntaxe du langage.

Les programmeurs indisciplinés écriront du mauvais code, peu importe la langue.

Intrigantes que python, qui vient par convention privée (_ préfixe), ne pas faire aucun effort pour la police cela, et beaucoup de code amende est encore en cours d' écriture.

Rant: Parfois, je pense que des langages plus permissifs forceraient plus de gens à apprendre à coder correctement, plutôt que l'inverse (c'est-à-dire que Java est unidirectionnel et que vous êtes maudit si vous voulez considérer les fonctions comme des objets de première classe).

Je devine: probablement pas. Pourquoi? Parce que vous devez coder le «pourquoi» comme formalisme dans la langue et parce que le «pourquoi», qu'il soit codé en langage ou en commentaire dans la langue, est de toute façon sous-utilisé par les programmeurs.

Le code peut certainement être auto-commenté en expliquant ce qu'il fait, mais il n'est pas toujours possible pour le code d'expliquer pourquoi il le fait. C'est là que les commentaires sont les plus nécessaires.

Si, par exemple, une section de code est nécessaire pour se conformer à une réglementation spécifique, comment l'expliquez-vous sans commentaire? Si l'algorithme utilisé par un morceau de code particulier est décrit dans un article écrit en 1998 par M. Matsumoto et T. Nishimura, comment expliquez-vous cela sans commenter? Si un algorithme ne fournit pas exactement la fonctionnalité optimale mais fait un compromis justifié très spécifique qui peut provoquer des problèmes futurs si un autre code est modifié, comment expliquez-vous cela sans un commentaire?

Que se passe-t-il si une section de code a été auditée par un auditeur indépendant de sorte qu'elle ne peut pas être modifiée sans invalider cet audit et que le code est utilisé pour créer un produit dont la conformité à cet audit est exigée par vos clients. Comment l'indiquez-vous sans commentaire?

J'ai toujours pensé qu'il serait bien d'avoir un commentaire d'un mot afin que si vous préfixez un mot avec un symbole (disons deux points), ce mot soit ignoré. De cette façon, vous auriez pu dire un peu que cela ne permettait que des commentaires d'un mot à l'intérieur d'une expression s. Par exemple, vous pouvez activer ceci:

(if (= x y)
    x
    y)

... dans ceci:

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

Si vous devez absolument le faire, vous pouvez enchaîner plusieurs commentaires d'un mot pour former un commentaire en ligne:

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

Bien sûr, c'est difficile à taper. En fait, c'est le point. Il vous encourage à utiliser les commentaires en ligne avec parcimonie et à les garder courts et précis. Mais j'ai le sentiment que j'aurais du mal à convaincre quiconque d'utiliser la langue.

C'est double ou rien. Certains programmeurs ne font rien pour rendre le code lisible. Ne pas autoriser les commentaires renforcera cela. Certains programmeurs écrivent de bons commentaires, même s'ils seraient encore meilleurs s'ils étaient du refactoring de code plutôt que des commentaires - la suppression des commentaires peut les forcer à faire le meilleur refactoring.

Raisons pour lesquelles c'est une bonne idée: - Aucune

Raisons pour lesquelles c'est une mauvaise idée: - Il y a beaucoup plus de programmeurs atroces que de bons mais pas très bons programmeurs - Il devrait presque toujours y avoir des commentaires pour des accrochages étranges, des résumés, etc. - Même si vous évitez les commentaires, vous utiliserez probablement les commentaires comme une étape sur le chemin: ajoutez un commentaire lorsque vous écrivez quelque chose, puis revenez le refactoriser. Mais vous ne pouvez pas toujours le faire immédiatement, car vous apprenez toujours. - Cela encouragera les gens à travailler autour de lui - Qui l'utiliserait? Les gens qui écrivent du code illisible et veulent une excuse (mauvaise) et les gens qui sont déjà amoureux de l'idée (qui peuvent simplement "ne pas écrire de commentaires" pour commencer). Si c'est ce que vous voulez, écrivez simplement une norme de codage montrant comment vous voulez que les gens le fassent.

Raisons pour lesquelles cela peut être pertinent - Lorsque cela pourrait être utile, c'est dans le cadre d'un système visant à améliorer le «non-commentaire», par exemple. une langue ou un IDE qui a un bon support pour quelque chose de mieux que des commentaires et dans le cadre de son discours, évite les commentaires. Je ne sais pas comment cela fonctionnerait, mais c'est un bon point qui mérite au moins réflexion.