Un langage qui n'autorise pas les commentaires donnerait-il un code plus lisible? [fermé]


15

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?


44
Pensez-vous qu'il existe une différence entre un langage qui n'autorise pas les commentaires et les développeurs qui ne les utilisent pas?
Jeremy Heiler

21
L'idée que l'interdiction des commentaires obligerait les développeurs à écrire davantage de code auto-documenté est absurde.
Adam Crossland

2
@Jeff qui est une fonction IDE / éditeur et non une fonction langugae IMHO
jk.

4
je ne suis pas sûr qu'il soit possible de forcer les développeurs à faire quoi que ce soit
jk.

2
@Adam @ jk01: ils ont même un langage qui oblige les développeurs à indenter le code d'une manière spécifique ;-)
Joris Meys

Réponses:


61

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

string aComment = "This is a kludge.";

7
J'aime la façon dont ce "commentaire" a plusieurs couches
Logan Capaldo

29
Un avantage supplémentaire est qu'il ira dans le binaire, vous pouvez donc y voir les commentaires aussi! Rend l'ingénierie inverse beaucoup plus simple.

1
Tu as raison. Nous devrions plutôt utiliser des instructions #ifdef.
James

9
C'est probablement le meilleur exemple de "programmation dans un langage" par opposition à "programmation dans un langage" que j'ai jamais vu. =)
gablin

2
Dans MOO, les commentaires sont pris en charge, mais tous les programmes sont analysés pour le stockage et non analysés pour l'affichage, de sorte que les commentaires sont perdus. L'idiome pour les commentaires persistants est les littéraux de chaîne ala"this is a comment";
Ben Jackson

44

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.


13
+1 pour les commentaires étant plus qu'une simple narration de ce que fait le code. Même le meilleur «code auto-documenté» doit avoir des commentaires pour l'élaboration de nombreuses choses. Souvent, le code aura des dépendances externes, des hypothèses d'entrée, des mises en garde, des zones améliorables, des vulnérabilités connues et d'innombrables autres choses qui ne sont jamais reconnues autrement. Les commentaires ont de nombreuses utilisations.
Adam Crossland

3
Exactement. Comment enregistrez-vous «intention» ou «pourquoi» ou «preuve d'exactitude» sans commentaires?
S.Lott

2
D'accord, les commentaires doivent être "Pourquoi" et non "Quoi". Quiconque ne peut pas obtenir le contenu du code ne doit pas le lire.
Matthew Read

3
@Matthew: Pour être honnête, vous pouvez facilement écrire du code qui n'est pas facilement déchiffrable. Mais oui, le code lisible est la meilleure source pour "quoi".

14

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).


11

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.


6

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.


1
Je lis du code avec ceci: argument = 3.0; aa = sqrt( argument ); bb = f( aa ); Soupir.
S.Lott

Cobol est une langue spéciale. Mais le "." L'opérateur est mal !!! Cela brise en quelque sorte la syntaxe d'une phrase.
Loïc Faure-Lacroix

3

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...


2

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.


En supposant qu'il n'y a pas de limite au nombre de méthodes, pourquoi ne refactorisez-vous pas simplement vos blocs de code en méthodes applicables, puis donnez-leur des noms descriptifs (ou plus de commentaires, dans votre cas)? Dans la plupart des "bons" codes que j'ai vus, les méthodes sont rarement plus longues qu'environ 10 lignes, et c'est assez évident ce qu'elles font.
Scott Whitlock

@Scott - Je suis un ardent défenseur du fait que le code devrait être auto-documenté et que les commentaires en ligne doivent être évités, mais les interdire explicitement est exagéré.
Jason Baker

@Jason - Je suis d'accord avec vous, mais je ne suis tout simplement pas d'accord avec l'idée que sans commentaires en ligne, c'est "des ordres de grandeur pires".
Scott Whitlock

@Scott: Vous obtenez beaucoup de commentaires comme "la raison pour laquelle nous faisons la vérification nulle bizarre sur la ligne 37 est ..." et ensuite vous devez feuilleter vos yeux entre le code et les commentaires. Il serait beaucoup plus facile d'avoir ce commentaire au-dessus de la ligne 37.
Xodarap

2

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.


"un langage / syntaxe / idiome docblock standardisé": ne doxygenfonctionnerait pas pour cela? en.wikipedia.org/wiki/Doxygen
sleske

Doxygen est un outil de documentation, identique à phpdocumentor et la chose qui génère la documentation Java à partir de javadoc (homonim?). Ce que je veux dire, c'est que le langage / syntaxe / idiomes faisait partie du langage de programmation lui-même, et non un commentaire qui doit être analysé pour les balises / propriétés.
dukeofgaming

4
Ainsi, vous évitez les commentaires en les appelant autrement.
Nate CK

2

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.


1

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?


3
Si vous pouvez le résumer en une seule ligne, vous pouvez nommer une fonction ou une méthode suffisamment descriptive pour expliquer ce qu'elle fait.
Scott Whitlock

1

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.


1
La programmation alphabétisée offre un langage qui n'a pas besoin de commentaires. Vous rédigez votre document, qui comprend toutes les explications nécessaires, le support, la preuve, l'intention, les compromis, les kludges, etc., ainsi que le code. Étant donné que le code n'est pas destiné à être autonome, il fonctionne bien.
S.Lott

@DisgrunteldGoat: oubliez ça. Il faudrait partir d'une langue particulière, et je ne parle que 5. Toutes les autres langues, je serais aussi perdu que tu le serais en néerlandais.
Joris Meys

Concernant le deuxième paragraphe: bien sûr que vous le pouvez. Prenez toutes les langues actuelles qui offrent la prise en charge des commentaires et supprimez la prise en charge des commentaires. Si ces langues avaient besoin de commentaires, alors elles seraient dans le code compilé ou l'interpréteur ferait autre chose que de les ignorer.
Kit

1

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).


1

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.


1

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?


0

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.


Il est également difficile à lire, ce qui empêche l'utilisation des commentaires pour rendre le code plus lisible.
Nate CK

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.