Просто из любопытства я начал задаваться вопросом, даст ли язык, который не допускает комментарии, более читабельный код, поскольку вы были бы вынуждены написать код с само-комментированием.

Опять же, вы можете написать такой же плохой код, как и раньше, потому что вам все равно. Но что ты думаешь?

Я думаю, что программисты нашли бы другой способ добавить комментарии ...

string aComment = "This is a kludge.";

Я не думаю, что это так просто:

даже в хорошо написанном, самодокументированном коде есть законные ситуации, когда вы должны писать комментарии.

Предположим, вы идеальный программист (а вы нет, но давайте просто предположим) ...

Есть много неочевидных эффектов, которые могут возникнуть в коде, когда вы взаимодействуете с вещами, которые вы не написали. Например, могут быть недостатки дизайна в чужой библиотеке или (если вы разработчик ядра) в чужом оборудовании. Наличие комментариев, объясняющих, почему вы использовали конкретный kludge в определенном месте, может иметь важное значение для понимания кода, и чтобы убедиться, что kludge не удален (что-то разрушает).

Мне трудно сосредоточиться на мысли, что удаление опций из языка каким-то образом улучшит программы, написанные на этом языке. Комментарии не являются обязательными, и написание самодокументируемого кода также не является обязательным.

Ничто не заменит хорошие практики развития.

Теоретически, COBOL изначально разрабатывался таким образом, чтобы обеспечить самодокументирование настолько, чтобы даже не разработчики (то есть супервизоры) могли просматривать написанный код и определять, что происходит. Однако на практике, поскольку программа становится все более сложной, трудно понять все, что происходит исключительно через код.

В то время как удаление комментариев может заставить некоторые разработчик к коду записи , что лучше при самостоятельной документации, есть еще разработчики, что там записи плохо документированная кода (т.е. имена переменные a, b, cи т.д.) , и это те привычки , которые люди должны быть обучены из из из. В этих случаях удаление комментариев не затронет этих разработчиков и может помешать усилиям других разработчиков объяснить сложные фрагменты кода.

Каждая программа написана для реализации функциональных требований, которые находятся вне программы, независимо от того, записаны они или просто находятся у кого-то в голове.

Я думаю, что наиболее важной функцией комментариев является установление соответствия между требованиями и кодом. Причина, по которой необходимо сопоставление, состоит в том, чтобы допускать постепенные изменения. Когда происходит изменение требований, необходимо внести соответствующие изменения в код, если код должен оставаться решением требований. Комментарии служат дорожной картой для изменений.

Если язык является идеальным предметно-ориентированным языком (DSL), идеально адаптированным к решаемой проблеме, тогда отображение должно быть простым изоморфизмом, и комментарии не будут необходимы. Исходный код просто установит проблему, и больше ничего не нужно будет говорить. Решение проблемы было бы похоронено в реализации языка.

Поскольку языки, на которых мы работаем, не являются такими DSL и останутся такими в течение некоторого времени, нам все еще нужны комментарии . Это вопрос степени. Иногда проблема заключается в том, чтобы найти подходящий язык, но обычно нет.

Смотрите также...

Я работаю где-то, что не позволяет встроенные комментарии (то есть вы можете иметь комментарии только в верхней части функций). Нет, это не облегчает чтение кода. Это делает это на порядок хуже.

Я избегаю комментирования кода, и он работает.

Я избегаю всех комментариев в коде (inline или stream) в пользу docblock + значимых переменных + спартанского программирования , и это работает.

И да, я знаю, что docblocks - это технически комментарии, тем не менее, они фактически дополняют код, а не навязчивы и «стандартизированы» ... все, что не является общим комментарием.

То, что я думаю, может работать как замена комментариев: стандартизированный язык docblock / синтаксис / идиома, что-то вроде аннотаций в java.

Мало того, что это не повлияет на качество - как заметили другие, это будет действительно раздражающим.

Я уверен, что большинство из нас время от времени делают что-то подобное:

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

Насколько раздражающим было бы, если бы вы не могли закомментировать несколько строк кода, чтобы выяснить, откуда эта ошибка?

Независимо от комментариев о том, как работает код, простые практические вещи, подобные этому или добавление удобной TODOзаметки, - это вещи, которые облегчают исправление незначительных проблем и запоминание того, что мы делали, когда начинали писать код.

Комментарии похожи на краткое изложение книги. Конечно, вы можете понять все, читая код, но с какой стати вы хотите прочитать целую страницу, когда она может быть сведена в одну закомментированную строку?

Хотя я согласен с другими ответами, что даже самодокументируемый код требует комментариев, это относится только к текущим языкам.

Я думаю, что реальный вопрос заключается в следующем: «Можно ли разработать новый язык программирования, который не нуждается в комментариях?» Это должно быть довольно высокий уровень с большой абстракцией. Каждое утверждение и функция должны быть доступны для чтения через синтаксис языка.

Недисциплинированные программисты будут писать плохой код, независимо от языка.

Интригует тот python, который просто имеет приватное соглашение (_-префикс), не прилагает никаких усилий, чтобы контролировать это, и много хорошего кода все еще пишется.

Рэнт: Иногда я думаю, что более разрешительные языки заставили бы больше людей научиться правильно кодировать, а не наоборот (то есть, Java была бы односторонней и проклятой, если вы хотите думать о функциях как о первоклассных объектах).

Я угадаю: вероятно, нет. Почему? Потому что вам придется кодировать «почему» как формализм в языке, а потому что «почему», независимо от того, кодируется ли он на языке или на языке комментариев, программисты все равно не используют.

Код, безусловно, может комментировать себя, объясняя, что он делает, но код не всегда может объяснить, почему он это делает. Именно здесь комментарии наиболее необходимы.

Например, если для соответствия определенным правилам необходим фрагмент кода, как вы объясните это без комментариев? Если алгоритм, используемый конкретным фрагментом кода, описан в статье, написанной в 1998 году М. Мацумото и Т. Нисимурой, как вы объясните это без комментариев? Если алгоритм не обеспечивает точно оптимальную функциональность, но делает очень конкретный оправданный компромисс, который может вызвать будущие проблемы, если другой код будет изменен, как вы объясните это без комментариев?

Что если один раздел кода был проверен независимым аудитором, поэтому его нельзя изменить, не аннулировав этот аудит, а код используется для создания продукта, соответствие которого этому аудиту требуется вашим клиентам. Как вы указываете, что без комментариев?

Я всегда думал, что было бы неплохо иметь комментарий в одно слово, чтобы, если вы добавили слово с символом (например, двоеточие), это слово было бы проигнорировано. Таким образом, вы могли бы сказать, что он допускает комментарии только из одного слова внутри s-выражения. Например, вы можете включить это:

(if (= x y)
    x
    y)

... в это:

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

Если вам абсолютно необходимо, вы можете объединить несколько комментариев в одно слово, чтобы сформировать встроенный комментарий:

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

Конечно, это боль набирать. На самом деле, в этом все дело. Он поощряет вас экономно использовать встроенные комментарии и делать их краткими и точными. Но у меня такое чувство, что мне будет сложно убедить кого-либо использовать язык.

Это двойной или ничего. Некоторые программисты ничего не делают, чтобы сделать код читабельным. Недопущение комментариев усилит это. Некоторые программисты пишут хорошие комментарии, даже если им было бы лучше, если бы они занимались рефакторингом кода, а не комментариями - удаление комментариев может заставить их выполнить лучший рефакторинг.

Причины, по которым это хорошая идея: - Нет

Причины, по которым это плохая идея: - Есть намного больше жестоких программистов, чем хороших, но не очень хороших программистов - Почти всегда должны быть некоторые комментарии для странных ошибок, резюме и т. Д. - Даже если вы отказываетесь от комментариев, вы, вероятно, будете использовать комментарии как этап на пути: добавьте комментарий, когда вы пишете что-то, а затем вернитесь и выполните рефакторинг. Но вы не всегда можете сделать это сразу, потому что вы все еще учитесь. - Это побудит людей работать вокруг него - Кто бы это использовал? Люди, которые пишут нечитаемый код и хотят оправдание (плохое), и люди, которые уже очарованы идеей (которые могут просто «не писать комментарии» для начала). Если это то, что вы хотите, просто напишите стандарт кодирования, показывающий, как вы хотите, чтобы люди это делали.

Причины, по которым это может иметь отношение - Где это может быть полезно, это как часть системы, чтобы сделать «не комментирование» лучше, например. язык или IDE, которые имеют хорошую поддержку для чего-то лучше, чем комментарии, и, как часть своей темы, избегают комментариев. Я не знаю, как это будет работать, но об этом стоит задуматься.