Я заметил, что в компании, которую я консультирую, постоянно делают в коде комментарии о том, какой баг они закрывают. Я уже несколько раз их пинал - удаляйте это дерьмо из кода, не пишите комментарии типа:
#тикет 5677 пофиксил херню
Это же выглядит ужасно, противно и уже через год на большом проекте весь код превратится в сплошные комментарии. И это дерьмо я увидел в очень крупной компании. Очень, очень крупной.
Блин, ну у вас же есть TFS и в нем можно посмотреть изменения. Неужели там нельзя узнать, кто изменил строку и для какого комита? Если этого нельзя сделать, то зачем вы вообще используете TFS?
Бесплатный git без проблем может выполнить команду git blame, и покажет, кто и когда менял строки. В самом комите уже будут комментарии, какое изменения были внесены, почему и какой баг фиксили. Ненужно срать комментариями в коде, для этого есть системы контроля версиями.
Если TFS не позволяет блеймить строки кода, то хватит платить за него огромные деньги, переходите на git и не срите в коде комментариями.
То же самое касается и кода - почему его не удаляют? Не комментируйте ненужный код, он должен беспощадно удалятся. Если нужно посмотреть историю, для этого есть системы контроля версий.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Я понимаю что вы самоучка и о настоящих стандартах программирования знаете столько же сколько про состав ядра венеры, но люди то стараются придерживаться этих стандартов. А вы им предлагаете говнокодингом заниматься.. Нехорошо Михаил.
Я в начале карьеры так делал, пока не понял суть VCS
А можно увидеть этот стандарт, в котором утверждается, что нужно делать такие вещи?
Т.к. я не никогда не пользовался такими системами, появился вопрос: записывают ли эти системы какая именно часть кода была изменена? или только когда и кем?
Тоже не понял комментария "Ex."
Любые комментарии в коде должны быть помещены туда обдумано. Ничего лишнего.
Закоментированные куски кода должны сразу вырезаться с возможностью восстановления из VCS.
Комментарии должны появляться когда без них действительно никак и должны описывать то, почему сделано так, а не описывать что сделано.
Что сделано и так написано кодом.
Общая идея изменения должна быть записана в VCS с обязательным описанием что изменено, а не просто "Fix #1314".
У нас, к примеру, баг трекер менялся уже 3 раза и коммиты с "Fix #1314" из старого трекера просто стали не информативными ниразу.
У нас в конторе используют JIRA + естественно Bitbucket. Так что обычно если что-то пофиксено или добавлено, то это можно понять из заголовка commit'а.
В коде обычно либо reference на копипасту, либо to do метки, либо пометки в духе не удалять закоментированные строки потому то и потому то.
В целом, если у вас большинство в компании придерживается противоположной вам стратегии в комментировании то зачем вообще лезть со своим уставом?
2Ex. Полный бред. Придерживаться таких "стандартов" и есть говнокодерство. Да и это не стандарты, а конвенция, если уж на то пошло.
Это какие-то пережитки прошлого. Почитайте как ведут своей проект github или другая контора.
Для этого и нужны VCS, чтобы хранить историю изменений, чтобы можно было "поблеймить", посмотреть логи изменений, откатиться и т.д.
А если за один комит изменялась куча разных файлов, в каждом будешь проставлять комментарии, а старый код комментировать?
Да и где ты видел нормально образование по software engineering в России? ШАД ИТМО Баумэнка МФТИ МГУ и еще пару вузов? Я учился на программиста, хороши были только фундаментальные предметы, высшая математика, все остальное посредственно.
2ex, если можно, поделитесь пруф линком по теме. Я в этом вопросе поддерживаю Михаила. На фига засорять код не нужными комментариями? До внедрения систем контроля версий мы тоже баловались подобным "стандартом". Через два года, код пестрил комментариями с номерами фиксов. Забавны были ситуации, когда фиксы накладывались друг на друг :-) Переход на гит решил эту проблему. Вот теперь хочу посмотреть на стандарт о котором не знаю :-)
Думаю эта привычка пошла с тех времен когда не было систем контроля версий. Как если нет истории можно посмотреть кто и по почему написал код. А привычки ох как тяжело меняются
Ну может Ex просто работает в этой компании? Просто это компания большая с офисами по всему миру и поэтому у него принято так писать. Ex = ты где работаешь, если не секрет?
SAP
Ощущение что всем тут по 15 лет. "Меняться надо, не засорять код". А потом сами них.. найти не могут что поменяли, а со временем поиск первопричин на крупных проектах со всеми этими системами контроля версий затягивается на недели. Их не используют ни в Oracle ни в MS ни у нас. Из тех с кем я поработал плотно.
Попробуйте использовать git, и поиск у вас займет секунды. Я не знаю, как это в TFS, с ним я работал мало. Про MS и Oracle не знаю, а те компании, где я работал, так не мусорят. Код Linux открыт, интересно, там такие комментарии есть?
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
