пруф или http://freelansim.ru/tasks/51718

@kurkuma >1 отклик Куркума, ну отдай мне эту работу!

> Читаемый, структурированный код с комментариями, в комментариях объяснение что в данном месте делается (в итоге код будет опубликован в опенсорс проекте и будет доступен для свободного использования) Что за говно? Код либо читаемый, либо с комментариями. Если в комментариях объясняется, что делается в коде -- значит код нечитаемый.

@kb комментарии читаются быстрее чем любой код

ты работодатель чтоли лол?

@kb если в коментариях объясняется НАХУЯ так сделано, то норм. ты ведь не можешь знать по каким костылям прошелся и автор и почему выбрал именно такое решение.

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

@kurkuma > код читаемый без костылей получился такое бывает только в еще не написаных исходниках хаскеле.

@4da ну и пусть, зато сколько звездочек на гитхубе соберем, понимаешь?

@kurkuma думаешь больше чем у них -> https://github.com/irungentoo/ProjectTox-Core ?

Целых 10к за такую ерунду, мило.

@engineer сделаешь?

@4da А железо самому покупать? И ТЗ надо бы посмотреть.

@engineer лол

@kurkuma куркума проигрывают с луддитов

@kurkuma Тут программа меньше 200 строчек будет наверное, просто же. Правда зависит от типа пульта.

@engineer 200 строчек на js

@kurkuma Комментарии читаются не быстрее чем правильный код.

@4da Для костылей комментарии нужны, но давайте не обсуждать костыли как метод разработки. Понятное дело, что не существует "правильного метода работы с костылями".

@kb коментарии нужны для любого кода, который неочевиден

@4da зачем писать неочевидный код?

@4da точнее понятно, что он будет, это и есть костыли, собственно, но требование "обильно писать комментарии ко всему коду" -- всё равно, что требование писать неочевидный код (и потом обильно его описывать комментариями)

@kb я не утверждаю что надо писать коментарии ко всему коду, а только описывать свои design decisions и rationale за ними.

@kb нет

@4da ну в README опиши общий дизайн, хуле в коде делать "решил тут въебать паттерн визитор"?

@4da комментарии нужны для любого кода, потому что в комментарии плотность информации выше и парсится она быстрее. проще прочитать предложение в каментах о том что делает метод ниже чем парсить десятки строк кода и пытаться интерпретировать его в голове. //сейчас кто-то кукарекнет про нейминг методов

@kurkuma в комментариях плотность меньше и парсится она дольше, т.к. комментарий не способен описать всё происходящее, также поэтому приходится сам код тоже читать (поскольку комментарий все подробности не описывает), а читать его сложнее из-за огромного количества комментариев.

@kb ты щас описываешься какие-то свои субъективные проблемы

@kb комментарий не должен описывать максимально точно, он должен описывать поверхностно, чтобы сразу было ясно тут то что ты ищешь или нет. а каменты уровня "складываем две переменные и кладем в третью" на каждой строчке - это пиздец, да

@kurkuma ну так блять, назови функцию "searching_for_foo" и не выёбывайся. а то понаделывают "def add_two_numbers(a, b): """Adds two numbers""" " блять

@kb уау, креативно // хули ты мне тут, далеко не всегда можно уместить понятное описание метода в название. в add_two_numbers конечно не нужен комментарий, но полно мест где он нужен и сэкономит время читающему