Основы программирования. Часть 1.
Ссылка на прошлую часть: http://pikabu.ru/story/_3219983
А я, внезапно, плюсану. Хотя бы за посылание нах в гугл и призывы сначала думать, а потом донимать тупыми вопросами. И за DRY, комментарии и призывы делать нормальное форматирование. Хотя вместо комментов лучше самодокументирующийся код, конечно.
раскрыть ветку (14)
Самодокументирующийся код - это миф. Конструкции вида i++ или setTimeout(fn, 500) не являются самодокументируемыми - ЧТО они делают понятно, но вот ЗАЧЕМ уже нет, и без внятного комментария тут уже не обойтись.
раскрыть ветку (13)
Нет, не миф.
Берешь кусок кода вида:
//делает Х из Y
Y y = new Y();
... 250 строк конструкций вида i++ и setTimeout(fn, 500) для преобразования из Y в X ...
Заворачиваешь в функцию\метод с сигнатурой X сделатьХизY(Y y);
Заменяешь код функцией и получаешь:
//делает Х из Y
Y y = new Y();
X x = сделатьXизY(y);
Упрощаешь:
//делает Х из Y
X x = сделатьXизY(new Y())
Комментарий превращается в капитанство и становится не нужным, т.к. код самодокументирован: входные\выходные параметры в сигнатуре видны, название функции поясняет что она делает, а не документируемые конструкции вида i++ сидят в теле функции и не мозолят глаз.
Спонсором этого комментария был Стив МакКоннел.
Берешь кусок кода вида:
//делает Х из Y
Y y = new Y();
... 250 строк конструкций вида i++ и setTimeout(fn, 500) для преобразования из Y в X ...
Заворачиваешь в функцию\метод с сигнатурой X сделатьХизY(Y y);
Заменяешь код функцией и получаешь:
//делает Х из Y
Y y = new Y();
X x = сделатьXизY(y);
Упрощаешь:
//делает Х из Y
X x = сделатьXизY(new Y())
Комментарий превращается в капитанство и становится не нужным, т.к. код самодокументирован: входные\выходные параметры в сигнатуре видны, название функции поясняет что она делает, а не документируемые конструкции вида i++ сидят в теле функции и не мозолят глаз.
Спонсором этого комментария был Стив МакКоннел.
раскрыть ветку (12)
Гениально! Что прикажешь делать, если задача стоит как раз разобраться в том, что происходит внутри такой функции, где сидят все инкременты и прочие таймауты? Все что ты написал является демагогией, которая по сути обозначает "твой код дерьмо, перепиши его правильно, и комментарии не понадобятся", что является не правдой - не самодокументируемые конструкции сами по себе не являются признаком плохого кода, а значит они будут даже в хорошем коде ипояснения того, зачем конкретно они используются в любом случае нужны. То, что сказал ты - есть всего лишь предложение прятать сложность.
раскрыть ветку (11)
В коде всегда где то будет такого рода говно. Вопрос лишь в том где именно оно, от этого зависит сложность поддержки проекта. Если такой код равномерно размазан про всему проекту то пахнуть будет весь проект, а если аккуратно разложан по "говорящим" или документированным функциям, то достаточно написать юнит тесты как минимум для этих функций, чтобы раз и навсегда забыть о них. Практика показывает, что разобраться в том что происходит внутри такой функции таки реально, хотя иногда проще написать её заново и говорящее название функции и юнит тесты сильно в этом помогают.
Да, как ни печально но по другому никак, от такого говна не избавиться даже в красивых функциональных языках. К тому же чем низкоуровневее задача тем больше подобных вещей.
Да, как ни печально но по другому никак, от такого говна не избавиться даже в красивых функциональных языках. К тому же чем низкоуровневее задача тем больше подобных вещей.
раскрыть ветку (10)
Речь же не о говне, как таковом, а о том, что "комментарии не нужны". Таки нужны и в ряде случаев вменяемой альтернативы им нет. Видим в коде:
Thread.sleep(500);
ЧТО делает данный код абсолютно понятно, но во ЗАЧЕАМ он это делает может быть совершенно не очевидно, и никакие юнит-тесты и понятные названия методов тут не помогут. Тесты подтвердят, что код работает так, как должен, а название функции опишет ее предназначение. Но зачем понадобилось прерывать поток исполнения и почему конкретно на пол секунды - вот вопрос! И просто так это понять не получится. Именно тут спасает коментарий от использования которого нас предостерегают. Прочитаем, что соседняя софтина общается с БД по сети в которой на момент написания кода наличествуют дикие проблемы и сплошные коллизии, и этот слип тупо дает ей время таки достучаться до базы, что б было что нам отдавать, и что данный слип нужно из кода выпилить, как только проблема с сетью будет решена - и тут же все становится понятно.
Thread.sleep(500);
ЧТО делает данный код абсолютно понятно, но во ЗАЧЕАМ он это делает может быть совершенно не очевидно, и никакие юнит-тесты и понятные названия методов тут не помогут. Тесты подтвердят, что код работает так, как должен, а название функции опишет ее предназначение. Но зачем понадобилось прерывать поток исполнения и почему конкретно на пол секунды - вот вопрос! И просто так это понять не получится. Именно тут спасает коментарий от использования которого нас предостерегают. Прочитаем, что соседняя софтина общается с БД по сети в которой на момент написания кода наличествуют дикие проблемы и сплошные коллизии, и этот слип тупо дает ей время таки достучаться до базы, что б было что нам отдавать, и что данный слип нужно из кода выпилить, как только проблема с сетью будет решена - и тут же все становится понятно.
раскрыть ветку (9)
// TODO THIS CODE MUST BE REFACTORED ASAP
// TODO Remove sleep() and use async onConnected() listener.
Thread.sleep(DATABASE_CONNECTION_TIMEOUT);
Вот так должно быть, и не надо никаких коментариев.
// TODO Remove sleep() and use async onConnected() listener.
Thread.sleep(DATABASE_CONNECTION_TIMEOUT);
Вот так должно быть, и не надо никаких коментариев.
раскрыть ветку (6)
раскрыть ветку (5)
TODO не объясняет что делает код, он говорит, что должен сделать программист. Более того, после того как дело сделано - TODO удаляется.
раскрыть ветку (4)
В данном конкретном случае - да, но данный конкретный случай высосан из пальца. Можно точно так же высосать из пальца сто и одну причину нахождения там этого слипа или таймаута без необходимости в дальнейшем что-то делать, и тогда там будет не туду, а комментарий, объясняющий нафига этот код нужен, или не будет ничего и будет вопрос "а зачем ЭТО нужно и на что ОНО влияет?"
раскрыть ветку (3)
В большинстве слуаев слип не нужен, и часто его можно заменить на использование таймера или листенера.
Суть в том, что большинство "непонятного" кода можно переписать в более понятный вид. Но не всё. Типичный "неперписываемый" пример это всякий матан, преобразования графики, шейдеры, работа с низким уровнем, итп. Про такой код я уже говорил, выносишь его в отдельные функции, если считаешь нужным - комментируешь, в этом нет ничего страшного. Я не говорю, что комменты совсем не нужны, я говорю, что их можно и нужно минимизировать. А на счет писателей книг скажу просто: эти "теоретики" книгописатели говорят нам как правильно писать код, но сами они понятия не имеют о том, какие реальные задачи решают практики. Практикам приходится иногда идти на компромисы, и я не вижу в этом ничего плохого.
Суть в том, что большинство "непонятного" кода можно переписать в более понятный вид. Но не всё. Типичный "неперписываемый" пример это всякий матан, преобразования графики, шейдеры, работа с низким уровнем, итп. Про такой код я уже говорил, выносишь его в отдельные функции, если считаешь нужным - комментируешь, в этом нет ничего страшного. Я не говорю, что комменты совсем не нужны, я говорю, что их можно и нужно минимизировать. А на счет писателей книг скажу просто: эти "теоретики" книгописатели говорят нам как правильно писать код, но сами они понятия не имеют о том, какие реальные задачи решают практики. Практикам приходится иногда идти на компромисы, и я не вижу в этом ничего плохого.
раскрыть ветку (2)
Вот тут не спорю абсолютно и подписываюсь под каждым словом!
>> большинство "непонятного" кода можно переписать в более понятный вид
Можно. Но когда дедлайн жмет, работы еще дофига, а пятая точка вещует, что в следующий раз ты вернешься к этому быдлокоду лет через сто, то лучше сделать подарок завтрашнему себе и пространно описать в комментарии, что ты имел ввиду тем спагетти, которое имеет место быть. Пару раз я себя таким образом спасал...
>> большинство "непонятного" кода можно переписать в более понятный вид
Можно. Но когда дедлайн жмет, работы еще дофига, а пятая точка вещует, что в следующий раз ты вернешься к этому быдлокоду лет через сто, то лучше сделать подарок завтрашнему себе и пространно описать в комментарии, что ты имел ввиду тем спагетти, которое имеет место быть. Пару раз я себя таким образом спасал...
раскрыть ветку (1)
Моё скромное мнение. Подход zenDzee, когда есть время и желание. Вариант AstarothAst, когда нет чего-то одного.
Коментировать нужнотолько не очевидные моменты и "магические" константы, хотя в последнем случае достаточно просто толково дать имя. В остальных моментах, при нормальном написании кода, коментари излишни.
раскрыть ветку (1)
Спасибо, Кэп! :D Естественно комментировать нужно то, что в комментировании нуждается, а что в комментировании не нуждается - комментировать не нужно. Я-то про то, что вера в мифический самодокументируемый код наивна и опасна - всегда будут места, где самым оправданным решением будет старый добрый комментарий.