Подтвердить что ты не робот

Нужны ли комментарии для языка программирования?

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

ИСТИННЫЙ Клингонский воин не комментирует свой код!

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

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

Удаление возможности комментировать язык программирования означало, что я HAVE написал грамотный код, никаких исключений.

Так мне стало интересно, есть ли там какие-то языки, которые не поддерживают комментарии?

Есть ли действительно хорошие аргументы, чтобы не удалять комментарии с языка?

Изменить: нужны ли хорошие примеры комментариев?


P.S. > Мой язык хобби выше частично глупый, так что не стоит слишком много внимания уделять моей реализации, так же как и концепция комментариев, требуемых вообще

4b9b3361

Ответ 1

Я не уверен, что согласен с "Have" в заявлении "Удаление возможности комментировать язык программирования означает, что я должен писать грамотный код, никаких исключений", так как это не так, как если бы весь код документирован. Я предполагаю, что большинство людей напишут нечитаемый код.

Более того, я лично не верю в реальность самоочевидной программы или API в практическом мире.

Мой опыт ручного анализа документации по всем API для моей диссертации говорит о том, что слишком часто вам придется нести больше информации, чем вы могли бы передать только в подписи. Если вы исключите комментарии к интерфейсу с вашего языка, каковы альтернативы? Документация не является вариантом. Внешняя документация с меньшей вероятностью читается.

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

Ответ 2

Не комментируйте, что вы делаете, но ПОЧЕМУ вы это делаете.

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

Ответ 3

Ugh, не имея возможности быстро прокомментировать строку (или строки) во время тестирования, звучит мне раздражающе, особенно при написании сценариев.

Ответ 4

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

Места, где комментарии полезны:

  • Оставляя номер билета рядом с исправлением, будущие программисты могут понять бизнес-требования.
  • Объяснение особенно сложного взлома
  • Комментарий к бизнес-логике для фрагмента кода
  • Тесные описания в документах API, поэтому сторонняя организация может использовать ваш API

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

Ответ 5

В вашем коде две разные аудитории:

  • Компилятор
  • Люди, подобные нам

Если вы решите вообще удалить комментарии, предположение, которое вы принимаете, состоит в том, что вы будете обслуживать только компилятор и ни к чему другому.

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

Ответ 6

Мне любопытно. Как вы запрещаете кому-либо объявлять статическую строку, содержащую комментарий, а затем игнорируете переменную для остальной части func/method/procedure/battle/whatever?

var useless_comment = "Can we destroy our enemies?"
if (phasers on full) return Qapla'

Ответ 7

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

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

Ответ 8

Пока исходный код защищен авторским правом по умолчанию. Часто бывает приятно:

  • напоминайте человеку, читающему исходный код, что он подлежит защите авторских прав.

  • расскажите людям, какие условия лицензирования для этого файла исходного кода

  • сообщите им, смотрят ли они на защищенный торговый секрет

К сожалению, без комментариев это трудно сделать.

Ответ 9

Вам не нужно ни одного утверждения в вашем коде, потому что в режиме выпуска все они ушли. Но когда у С++ не было встроенных утверждений, кто-то написал макрос assert, чтобы заменить его.

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

HelperFunctionDoesNothing("This is a comment! Blah Blah Blah...");

Ответ 10

Я единственный, кто комментирует пару строк кода для нескольких целей?

Ответ 11

Хотя верно, что люди должны иметь возможность комментировать код, совершенно необязательно, чтобы язык напрямую поддерживал комментирование: для большинства языков было бы тривиально написать script, который удаляет один комментарий строки (например, все строки, начинающиеся с символа '#' или другого символа, затем запускают компилятор.

На самом деле, я удивлен и разочарован, узнав, что даже мои любимые языки эзотерического программирования поддерживают комментарии: Brainf ** k и Whitespace. Эти языки трудно читать, поэтому кажется, что они не должны поддерживать комментирование. (В отличие от моего другого любимого эзотерического языка: LOLCode, который должен быть самодокументирован, в lolcats-speech)

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

Ответ 12

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

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

Ответ 13

Не грамотное программирование, как комментарий, как код? Конечно, многое из того, что я видел в грамотном программировании, имеет такое же объяснение, как и код, если не больше комментариев.

Ответ 14

Вы можете подумать, что разработчики, пишущие на вашем языке, приложат дополнительные усилия для написания четкого кода, но бремя на самом деле будет на вам, чтобы создать язык, который настолько выразителен, что ему не нужно прокомментировать. Черт, даже английский не такой (мы все еще в скобках!). Если ваш язык не так разработан, он вполне может быть таким же полезным, как Brainfuck, и пользоваться популярностью и уважением Brainfuck.

Должен ли я добавлять ссылки или ссылки считаются комментариями?

Кроме того, люди найдут способы добавить комментарии, если им нужно, с помощью highjacking строк и неправильного использования имен переменных (которые не делают ничего, кроме комментариев). Вы читали Геделя Эшера Баха?

Ответ 15

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

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

Кроме того, мой опыт заключается в том, что новые программисты склонны комментировать больше, и, поскольку они развивают опыт, их код, как правило, становится документирующим и сжатым. В общем комментарии должны быть о ПОЧЕМЕ, а не КАК или ЧТО.

Ответ 16

НЕТ - нет ни одного языка программирования, который требует комментариев.

Язык для компьютера. Комментарии для людей. Вы можете написать программу с 0% комментариями. Это будет выполнено, правильно или неправильно. Вы не можете написать программу со 100% комментариями. Он либо не будет компилироваться - нет main() и т.д. - или, для языков сценариев, ничего не делает.

И, кроме того, настоящие программисты не комментируют свой код. Как и клингоны.

Ответ 17

Являются ли комментарии необходимыми для языка программирования?

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

Полезно ли для языка программирования предоставить конструкцию комментирования?

Да. Комментарии очень полезны для программиста, а не только для подделки, как они знают, что они делают, но и для отладки и полезного документирования.

Ответ 18

Пока я согласен с ответами Uri, я тоже сделал язык без комментариев. (ichbins.) Язык должен был быть как можно более простым, все еще будучи в состоянии выразить свой собственный компилятор чисто; так как вы можете сделать это без комментариев, их отбросили.

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

Удачи в взломе клингонов.: -)

Ответ 19

Я не могу сказать вам, насколько я благодарен Javadoc, что очень просто настроить в комментариях. Так что хотя бы один смысл, в котором комментарии полезны.

Ответ 20

Нет, конечно, язык не должен комментировать. Но (полезная) программа должна иметь комментарии... Я не согласен с вашей идеей о том, что в грамотном коде не хватает комментариев. Некоторые очень хорошие коды легко понятны с комментариями, но только с трудом.

Ответ 21

Я думаю, что комментарии требуются во многих ситуациях.

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

Без явного описания параметров и используемого алгоритма, используя комментарии, почти невозможно повторно использовать этот фрагмент кода.

Ответ 22

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

Ответ 23

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

Ответ 24

Это будет сложнее, чем вы думаете, чтобы создать язык, на котором комментарии невозможны.

if (false) {
    print("This is a comment. Chew on that, Klingons!")
}

Ответ 25

Я думаю, вопрос может стать тем, насколько самодостаточным будет язык без комментариев? Если, например, он компилируется до библиотек DLL, которые используются в другом коде, то как узнать что-либо помимо сигнатуры функции в терминах того, что требуется, изменений и возвратов? Я бы не хотел, чтобы имена функций были десятками символов, чтобы попытаться выразить то, что может быть очень легко сделано с комментариями над функцией, которая может быть использована в качестве документации внутри чего-то вроде обозревателя объектов в Visual Studio, например.

Ответ 26

Конечно!!

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

Мы все начинаем в какой-то момент.

Но если вы ориентируетесь только на "опытных" разработчиков, зачем беспокоиться на этом языке на первом месте. Вы должны использовать бабочки! Это то, что использует настоящий разработчик!

Комментарии обязательны, попробуйте сделать это сложнее, если хотите (например, использовать #//##/sequence для создания комментария или что-то в этом роде), но не оставляйте его.

:)

Ответ 27

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

Ответ 28

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

Ответ 29

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

Ответ 30

Любой код нуждается в комментариях, я пытаюсь объяснить причину и работу каждой функции, которую я пишу в 1 или 2 строках.

Кодекс, который объясняет, что он существует только в совершенном мире, всегда есть какой-то странный хак или причина сделать что-то быстро-грязное, а не путь. Самое лучшее, что нужно запомнить, это комментировать код ПОЧЕМА делает то, что он делает, хороший код объясняет, ЧТО это делает в 99% случаев.

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