Не напоминайте....
06.06.2018, 11:41
Не совсем, мода в ИТ формируется эффективностью практик (ну кроме проектов, где работают ребятки, которым пофигу как работать и они тупо обезьянят популярные практики без адаптации к проекту и команде).
Я согласен с рядовым, хороший код нуждается в минимуме комментариев, т.к. у нём названия переменных/классов/функций/методов точные и лаконичные, операции понятные и хорошо разделены в пространстве, "код читается как рассказ" ("Clean code", R. Martin). При такой ситуации комментарии становятся информационным шумом. Правда, части публичного API должны быть хорошо задокументированы в любом случае, некоторые языки/фреймворки позволяют генерить документацию прямо из комментариев кода.
Ну начинается виляние по экстремальным ситуациям, чтобы защитить свое мнение. Естественно местами приходится комментировать некоторые вещи, чтобы внести ясность или описать, почему сделано именно так, но комментить весь код не имеет смысла, так как для программиста это будет являться дублированием информации, ведь он уже умеет читать и понимать код, зачем ему еще и текстовое описание.
Шо то хуйня, шо то.
В первом варианте: имя заполнено кучей бесполезной информации, например волатильность и мьютабилити всегда очевидным образом выплывает из модификаторов переменной, а вместо писания всяких "убер-важная-переменная" стоит использовать нормальное имя описывающие предназначение переменной, использование разными процессорами (скорее всего ты имел в виду конкурентный доступ в нативной среде) - выглядит весьма стрёмно, доступ к такой переменной не может контролироваться просто именем переменной, явно вокруг неё всё говорит о конкурентном доступе к ней.
Второй вариант ещё хуже: "m - mutable" - это фольклор, который будет передаваться из уст в уста, покуда преемственность поколений разработчиков на проекте не прервётся, в части паблик API - это вообще катастрофа, первый вариант хоть сам о себе расскажет прямо в IDE, когда попытаешься посмотреть на состав класса. Сокращения и аббревиатуры (кроме самых распространённых и понятных из контекста кода) - плохая практика, могут быть неправильно поняты, расшифровки могут быть забыты и утеряны в веках.
ИМХО, лучше увидеть что-то вроде:
uiConcurrentAccessNumberOfFlyingDildosOnScreen, чем muiNOFDOS (mui меня наталкивает на одну известную песню Кати Лель)
В первом варианте: имя заполнено кучей бесполезной информации, например волатильность и мьютабилити всегда очевидным образом выплывает из модификаторов переменной, а вместо писания всяких "убер-важная-переменная" стоит использовать нормальное имя описывающие предназначение переменной, использование разными процессорами (скорее всего ты имел в виду конкурентный доступ в нативной среде) - выглядит весьма стрёмно, доступ к такой переменной не может контролироваться просто именем переменной, явно вокруг неё всё говорит о конкурентном доступе к ней.
Второй вариант ещё хуже: "m - mutable" - это фольклор, который будет передаваться из уст в уста, покуда преемственность поколений разработчиков на проекте не прервётся, в части паблик API - это вообще катастрофа, первый вариант хоть сам о себе расскажет прямо в IDE, когда попытаешься посмотреть на состав класса. Сокращения и аббревиатуры (кроме самых распространённых и понятных из контекста кода) - плохая практика, могут быть неправильно поняты, расшифровки могут быть забыты и утеряны в веках.
ИМХО, лучше увидеть что-то вроде:
uiConcurrentAccessNumberOfFlyingDildosOnScreen, чем muiNOFDOS (mui меня наталкивает на одну известную песню Кати Лель)
Я лишь привёл пример "самодокументируемого кода" и адекватного применения комментария, когда комментарий даёт ценную информацию без использования овердохуядлинного именования переменной. В книге Макконнелла эти все варианты описывают и объясняются почему и что нужно делать.
Цитировать даже 10% от этой книги здесь не вижу смысла.
Цитировать даже 10% от этой книги здесь не вижу смысла.
>нахуй комментить код
ПРЯМИКОМ В АД НАХУЙ
ПРЯМИКОМ В АД НАХУЙ
И где этот файл будет искать следующий мейнтейнер год/два/десять спустя?
причём тут качество?
некоторые решения могут быть неочевидными. для этого и комментарии, чтобы потом понять.
поэтому комментарии обьясняют не то, что делает код, а зачем он что-то делает.
некоторые решения могут быть неочевидными. для этого и комментарии, чтобы потом понять.
поэтому комментарии обьясняют не то, что делает код, а зачем он что-то делает.
Не знаю о чём и зачем вы тут спорите, но истина давно известна. В первую очередь и почти всегда комментарий должен повествовать не что делает этот участок кода (это должно быть очевидно глядя на сам код), а зачем этот код именно это именно так делает. Это автоматически нас приводит к тому, что обычно в хорошем коде комментариев немного (если не считать всякую мета-инфу в комментариях за комментарии), потому что каких-то неочевидных моментов (вроде костылей для сторонних библиотек или просто сильно хитрых решений) должно быть немного. Если же такие комментарии не оставлять, то новичок, придя на проект, ринется переписывать этот код так, чтобы было кошерно, и возможно у него даже не сразу всё там помрёт и отвалится. Он ведь не знает, что оно так сделано, потому что, скажем, в каких-то хитрых случаях какая-нибудь сторонняя либа валится в сегфолт, или скажем какой-нибудь Edge 13 не поддерживает какое-нибудь стечение обстоятельств, или какое-нибудь API нестабильно. Или что этот алгоритм в узко-нагруженном месте до микросекунд оптимизирован, и потому так странно выглядит.
Ну ещё бывают редкие случаи когда нужно комментировать не только "почему это здесь", но и "что это вообще такое". Но это уже большая экзотика, которую обычно можно отрефакторить.
Ну ещё бывают редкие случаи когда нужно комментировать не только "почему это здесь", но и "что это вообще такое". Но это уже большая экзотика, которую обычно можно отрефакторить.
взято отсюда? : https://m.habr.com/company/mailru/blog/412693/
Ну, современные стандарты написания самодостаточного/самоописывающего кода берут свои истоки в конце 90-х, а это уже почти 20 лет назад. Так что хороший код 20-летней выдержки должен быть всё ещё читабельным. А вот ПО начала 90-х и ранее - вот там фарш должен быть: фреймворков почти не было, писали как могли, тесты были кастомные...
если про меня - то и двух дней хватит
а иногда и два часа - если я на обед ходил
а иногда и два часа - если я на обед ходил
Он кстати умер, знаток этот. Андрей Жданов, жаль его, харизматичный мужик был.
http://www.mk.ru/social/2017/02/28/zagadka-smerti-andreya-zhdanova-chempiona-svoey-igry-pogubilo-razbitoe-serdce.html
http://www.mk.ru/social/2017/02/28/zagadka-smerti-andreya-zhdanova-chempiona-svoey-igry-pogubilo-razbitoe-serdce.html
у меня все коды направленны на то чтоб выводить сообщение "Я тебя не звал, иди на хуй"
2 года? Да я не могу разобрать что я 2 недели назад написал, когда ко мне пришел CEO и сказал "чтобы было вчера!"
Неделю назад ты написал код, сегодня у пользователя произошла ошибка (см. скриншот). Почему? На раздумье дается пол минуты
