Дело привычки, на самом деле. Тем более, что между словами, как ни крути, по-другому не получится быстрее перемещаться. Раньше приходилось много вордовских документов править, вот там действительно это спасение!
К сожалению, часто приходится применять методологию разработки «KDD», от слова «костыль» :) Все проистекает из того, что, к примеру менеджерам проекта кровь из носа требуется добавить функциональность, реализация которой «по-правильному» займет неделю, а клиент требует от них этого как всегда «вчера». Но самая засада, что менеджер имел в виду не то, что вы с ним утвердили. Это выясняется через неделю, и один костыль заменяется на другой с минимальными затратами… :D С идеалогической точки зрения это кажется злом, но это реалии. Посмотрите вот это видео, как раз в тему: vimeo.com/10922497
Согласен, но стоит трогать опять же, только при необходимости, иначе при огромных объемах кода, можно только и делать что рефакторить. Пожалуйста, учитывайте, что этим невозможно заниматься 100% времени, так как на разработчика в первую очередь сваливается «текучка» и новый функционал + поддержка работоспособности старого.
Речь не идет о проблемах с кодом. Речь о том, что с комментарием отпала бы необходимость читать код этой функции и сетовать на данную реализацию, какой бы она не была. В проекте может быть тысячи функций, вы предлагаете читать каждую?
Вы неверно поняли суть того, что я сказал.
Ситуация — приходит новый программист, который раньше никогда не вникал, как устроено, например, расписание сеансов кинотеатров и что текущий день заканчивается не в 24 часа, а в 6 часов утра следующего дня и функция, которая делает выборку, сделает не то, что нужно, если не будет делать временной сдвиг, принимая на вход период с 9:00 по 0:30, вернув промежуток за 8,5 часов, а не за 15,5. Мысль ясна?
На самом деле, принцип «работает — не трогай», часто спасает от траты времени и помогает не отвлекаться на все подряд. Если не работает или требуется использовать где-то еще данный участок кода — другой разговор, стоит потратить время и зарефакторить.
Рассмотрим реальный пример. Встречаете вы функцию, которая осуществляет фильтрацию данных на 200 строк. Объем кажется большим? Меньше ее врядли сделать — она формирует оптимальный и быстрый sql-запрос. На входе у нее массив, который должен содержать значения фильтров. Решение понятно — один входной параметр позволяет легко добавить/удалить фильтры. Почему входящие фильтры не сделаны через объекты? Потому что объем стал бы 1000 строк. Дополнительное условие — задача была горящая и требовала достаточно быстрой реализации. В итоге мы получаем в данной ситуации хорошую работающую функцию, но разработчик не указал в комментарии, какие входные параметры она принимает.
В итоге, каждый кто захочет использовать ее, должен будет читать все двести строк, чтобы понять в каком формате приходят входные данные и что они значат.
Пока что плохим программистом представляетесь лишь Вы. А у нас сложная и многогранная предметная область, сотня серверов, несколько миллионов строк кода, более сотни проектов и очень высокие нагрузки.
Ответ на мой комментарий с вашей стороны до нельзя банален и очевиден. Нет ничего проще, чем сослаться на книжку, из которой вы выудили не то, что нужно. Перестаньте бить себя в грудь доказывая откровенную чушь. Делетантами я назвал тех — кого назвал, не передергивайте. Я не считаю себя д'Артаньяном, так как всегда стараюсь расширять свой кругозор, ищу существующие решения и консультируюсь с людьми, которые разбираются в вопросе на моем уровне или имеют больше знаний и опыта. Моя совесть в этом вопросе чиста.
Да, и не следует, вообще говоря, делать из авторов книжек себе кумиров и авторитетов. Учитесь думать своей головой, принимая во внимание полученные знания из литературы.
Вы знаете, комментарии еще очень важны в рамках специфики определенных проектов. Ведь программисты не занимаются тупым кодированием в сферическом вакууме, их код отражает вещи, происходящие в реальном мире. Задача комментариев — помочь разобраться, почему эта функция работает именно так, а не иначе, как могло бы казаться. Комментарии помогают понять предметную область, с которой работает система.
В любом коде можно разобраться, но на это может уйти разное количество времени. Обычно еще при планировании задач закладываются часы на документирование кода. Я читал достаточное количество умных книжек и имел честь общаться с большим числом высоко квалифицированных разработчиков, а также имею свой большой опыт разработки — только дилетанты, не имеющие опыта работы в команде и работы над крупными проектами, считают отсутствие комментариев нормой.
Вы делите все на черное и белое — в реальной жизни так не бывает. Не бывает экстремальных ситуаций, когда код идеален или до бесконечности ужасен. Комментарии — это неотъемлемая часть документации.
Есть такое понятие — «исторически сложилось». Меняются разработчики, меняется их число и квалификация, стандартны кодирования, контроль над кодом. Разные команды разработчиков по-разному относятся к своим проектам и с разной долей ответственности. Одни делают ревью, другие дебажат на боевых серверах.
> Если код нормальный — комментарии не нужны.
Код может быть нормальным и вполне качественным, но реализовывать сложную логику, которую сможет быстро объяснить доступный комментарий. Это более чем отличная практика читать код по названию функций и комментариям к ним, а также пользоваться генераторами документации на основе комментариев. Заставлять других разработчиков рыскать по коду в поисках значения входных параметров — это просто моветон.
>Может еще меня в педофилии обвините из-за того, что я не поддерживаю комментирование?
Я бы вас уволил.
Проблема надумана. Откройте для себя комбинацию клавиш ctrl+стрелочка.
Ситуация — приходит новый программист, который раньше никогда не вникал, как устроено, например, расписание сеансов кинотеатров и что текущий день заканчивается не в 24 часа, а в 6 часов утра следующего дня и функция, которая делает выборку, сделает не то, что нужно, если не будет делать временной сдвиг, принимая на вход период с 9:00 по 0:30, вернув промежуток за 8,5 часов, а не за 15,5. Мысль ясна?
В итоге, каждый кто захочет использовать ее, должен будет читать все двести строк, чтобы понять в каком формате приходят входные данные и что они значат.
Да, и не следует, вообще говоря, делать из авторов книжек себе кумиров и авторитетов. Учитесь думать своей головой, принимая во внимание полученные знания из литературы.
Есть такое понятие — «исторически сложилось». Меняются разработчики, меняется их число и квалификация, стандартны кодирования, контроль над кодом. Разные команды разработчиков по-разному относятся к своим проектам и с разной долей ответственности. Одни делают ревью, другие дебажат на боевых серверах.
> Если код нормальный — комментарии не нужны.
Код может быть нормальным и вполне качественным, но реализовывать сложную логику, которую сможет быстро объяснить доступный комментарий. Это более чем отличная практика читать код по названию функций и комментариям к ним, а также пользоваться генераторами документации на основе комментариев. Заставлять других разработчиков рыскать по коду в поисках значения входных параметров — это просто моветон.
>Может еще меня в педофилии обвините из-за того, что я не поддерживаю комментирование?
Я бы вас уволил.