функциональное программирование и комментирование кода - это действительно возможно?

Question

Поскольку у меня было много свободного времени, чтобы тратить банкомат, я прочитал несколько веток / комментариев к комментариям к коду и документации здесь. Как и большинство людей здесь, я тоже думаю, что вы должны написать свой код, чтобы его было легко читать и комментировать, насколько это возможно. С другой стороны, я большой фанат FP - и да, если вы напишите свой код правильно, он будет очень читабелен в FP - или так я думал. Проблема в том, что крошечные вещи имеют огромное значение в мире FP. Если ваш коллега не полностью понимает FP, он может «прочитать» отступ кода, но не сможет изменить или полностью понять его. Это означает такие языки, как Хаскелл, где «.» или '$' имеет большое значение, а также для таких языков, как F # или даже C # в VB.NET с большим количеством операторов LINQ.

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

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

Так что ИМХО вам нужно комментировать свой FP-код, пока вы работаете в магазине, где не каждый коллега имеет докторскую степень в области CS;)

Что ты думаешь?

PS: первое сообщение здесь - действительно искал ответы на эти вопросы, но не нашел ни одного - будьте осторожны, если я просто не выгляжу достаточно усердно:)

Answer 1

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

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

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

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

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

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

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

Наконец, следует заметить, что консенсуса нет даже среди мастеров.Например, Деннис Ритчи известен тем, что чрезвычайно скуп на комментарии, вместо этого Дон Кнут является сторонником «грамотного программирования», где комментарии так же важны, как и сам код.Свод правил никогда не заменит личного вкуса.