❗❗Программисты, которые пишут на ООП языках, обращаюсь к вам, расширяйте свои знания! Регистрируйтесь на anvanced лекцию, которая состоится уже 29 августа в 15:00. Мы рассмотрим самые популярные паттерны GoF и разыграем 3 места на мой авторский тренинг GRASP & GOF Design Patterns. Присоединяйтесь к нам, регистрируйтесь - go.foxminded.ua/3yPdTeW
Видео описывает правильное комментирование кода, чтобы тот был читаем. Пишите «зачем мы это делаем», а не «что мы делаем». - вот вроде правильный коммент к видео
Как все таки хорошо что вас по прежнему зовут Сергей Немчинский))). Я каждый раз с опаской открываю видео и боюсь услышать что вас зовут как то по другому
@@andyvoice Вопрос про комментирование в embedded: частенько имеется большой участок кода, где регистры периферии заполняются конфигурационными значениями, или проверяются флаги системных событий. При этом даже из названий применяемых define не всегда понятно - что именно здесь происходит. Получается такой код все же допускает сквозное комментирование?
Кстати, работаю с индусам (вся команда из Индии), и они пишут так же, как и все. Не сказал бы, что их код чем-то отличается от остальных. В целом очень шарящие и позитивные ребята, короче :)
@@SergeyNemchinskiy Можна про умовних "індусів", тобто яких помилок програмісти (початківці і не дуже) найчастіше припускаються у своєму коді. З вашого досвіду, звичайно
@@SergeyNemchinskiy До речі, було б непогано в якості прикладу наводити скріни тих помилок, про які ви розповідаєте. Це, звичайно, в дусі "капітан очевидність", але, на мою думку, було б дуже наглядно і краще б запам’ятовувалося
Привычку к написанию капитанских комментариев часто формируют в учебных заведениях, заставляя студентов комментировать чуть ли не каждый шаг. Ох как меня это бесило. Сколько я срался с преподом из-за этого... - Зачем комментировать очевидные вещи? - Это для тебя они очевидные, а для других - нет!
Да, у нас тоже такая отбитая совковая преподша вела программирование. Требовала комментарии в каждой строчке, и обязательно на английском, но сама при этом английский не знала. Один чувак на потоке сдавал ей лабы с текстами группы Slayer в комментариях.
@@alexlightweight Вот не зря Сергей так топит за обучение с ментором: без критики от профессионала из отрасли легко уйти не туда (а то и вовсе не дойти). ИМХО, разработка хотя бы вдвоём по качеству кода, скорее всего, будет на голову выше разработки в одно лицо. А одному можно сидеть хоть 10 лет и не вырасти вообще.
@@alexlightweight Мне почему-то кажется, что если код настолько корявый, то и комменты были бы не сильно понятнее)) Но лучше, конечно, хоть какое-то объяснение, чем никакого.
@@alexlightweight У меня на самой первой работе была похожая ситуация. Ушёл оттуда, ибо было тяжело как мне с этими людьми, так и им со мной (я хоть и был без опыта, но теоретически уже понимал такого рода вещи). Они были намного старше, учились программировать где-то в восьмидесятые или начале девяностых, когда о хороших практиках программирования вообще мало кто слышал. И сейчас их уже не переучишь. Да и им это не интересно: для них-то всё работает, заказчик деньги платит, значит имеют право говнокодить как хотят (ну а я, соответственно, имею право поискать другое место работы, где взгляды программистов будут больше совпадать с моими).
Очень полезная информация! Спасибо! Было бы здорово после всех серий показать рабочий пример со всеми затронутыми темами и выложить его на git как шпаргалку ;)
Очень интересная тема! Жутко полезно, давно хотел найти развернутое пособие "Что такое хорошо, а что такое плохое" по комментариям. Сергей, так держать!
21:21 В языках с препроцессором (C/C++ и некоторые другие) комментарий о закрытии препроцессорного блока #if/#ifdef может выручать, если размер такого блока изрядный, или есть приличная вложенность подобных блоков. Просто облегчает поиск его окончания. Причём полезно дублировать в комментарии всю конструкцию изначального условия. #if SOME_DEFINE || OTHER_DEFINE > 0 ... 100500 строк. #ifdef DEBUG ... #endif // #ifdef DEBUG ... #else // #if SOME_DEFINE || OTHER_DEFINE > 0 ... 500100 строк. #endif // #if SOME_DEFINE || OTHER_DEFINE > 0 Обоснование: препроцессор это как бы "надязык", его конструкции переплетаются с кодом основной структуры программы, и зачастую не имеет отступов (так как это уменьшает наглядность кода или же такие отступы вступают в конфликт с отступами самого языка).
Qt автоматом добавляет такой коммент к концу Header guard-а для новых файлов. А для визуализации вложенности они у себя в коде отделяют пробелами # и команду препроцессору: #ifndef FOO # ifndef BAR # define BAR # endif #endif Но всё-равно препроцессор - это адский ад, сильно замусоривает код.
Когда нужно решить задачу в очень сжатый срок - приходится писать говно, и оставлять для себя на будущее комментарии - что и как потом переделать. Так что без TO DO вообще никуда
Доброго дня. Классный цикл лекций. Для прошареных наверно известные истины, для остальных же, хорошая подача. Интересно про взаимодействие в команде. Например фронт/бэк. Как разговаривать если ты делаешь систему, которая зависит от другой системы.
я не понимаю холивара вокруг комментов. Почему вдруг это стало такой обсуждаемой на каждом углу проблемой? Ну хороший код и не нужны комменты - красота, а если комменты есть - еще лучше. Я даже в собственном коде, который хорошо понимаю - оставляю комменты в первую очередь для себя, потому что мне проще врубиться в какие-нибудь алгоритмы фильтрации массивов, ключей и прочих циклов и шаманства, прочитав комменты, чем каждую строчку кода разбирать и пытаться вспомнить почему именно так делается и почему на входе получается один массив, а на выходе другой. За-то когда читаю чужой код с такой же магией - матерей разрабов в кино вожу, потому что им было лень написать 3 слова к своей конструкции и я должен тратить порой по нескольку часов, чтобы отдебажить каждую строчку кода и понять где собака зарыта. Просто есть шаблонный код, который ничего особого не выполняет и ты одним взглядом понимаешь что он выполняет, а бывают сложные алгоритмы, которые не с первого взгляда очевидны что они выполняют, как ты не упрощай код и как не называй ты те переменные, почему бы не оставить пару слов о том что выполняется в коде ниже. Я бывает в особых случаях даже каждую строчку комментирую в цикле, потому что было не раз такое, что возвращался к своему же коду, видел "ошибку" или какое-то "ненужное условие", удалял его, а потом ловил багулину, потому что оказывается оно там нужно было. После пары таких раз - решил класть на все эти ваши стандарты по клинкоду и писать так, чтобы любой индус разобрался. Особенно это актуально на старых и загаженных проектах, где все держится на подпорках из говна и палок. Это может на ваших там ААА проектах все чики-пуки, по всем современным стандартам в лице фреймворков, мне к сожалению такие видеть не доводилось.
спасибо, очень полезно, особенно для начинающих. мне уже давно советовали прочитать чистый код, а так слушая, тем более с примерами, на мой вкус намного яснее и понятнее становиться!!!
У меня коллега любит так методы и классы называть, пока никто не видит. А ты потом думай, что значит MessagePresenterTut. Что за Tut, нахера оно нужно и не скрывается ли за ним какой-то сакральный бизнес-смысл?
Оказывается я правильные комменты в коде пишу. По поводу комментария "Это мост". Часто видел у новичков коммент типа "Цикл for начало/конец". Блин я и без коммента понимаю что это while :). Про закомментированный кусок кода, раньше оставлял, авось пригодится, реально ни разу не нужен если ты его заменил на другой работающий код.
Нас, когда мы были студентами, заставляли комментировать языковые конструкции, типа for(...)//цикл от.. до.. А выделение начала-конца блока я и сам, будучи совсем зелёным, делал, ибо тогда ИДЕшки не умели в нормальную подсветку (кто помнит Delphi - привет).
@@0imax Нас при обучении, ни кто не заставлял комментировать вообще. Все комменты на свое усмотрение. Вот обучение было веселое: 1 курс - QBasic, 2- Turbo Pascal, 3 - Borland C++, 4 - Были разные предметы на которых каждый препод свой язык толкал и получилось что параллельно преподавались (Delphi, Visual Basic, Visual C++ MFC), 5 - только Visual Basic, хотя препод и не против если на C# или Java все сдашь.
Ладно. Тут понятно откуда ноги растут. Но не понятно от куда такие же ноги у тех кто сам пытается научиться программированию. Но сомневаюсь, что везде так преподают.
Для закоментированного кода есть специфический кейс. Когда просят вырубить фичу. Меняется программист. Просят врубить фичу. С ненулевой вероятностью новый программер напишет ее заново, если она не закоментарена, а удалена.
Закомментированый код - офигенная штука, когда ты - веб дев, сидишь на одном проекте годами и тебя периодически просят воткнуть на морде какой-то временный функционал. Или временно отключить какой-то функционал.
Сергей, спасибо за очередную полезную лекцию! Было бы по очень интересно послушать про хорошие и плохие коммиты. А то когда начинаю работать делаю коммит под каждый чих, а потом вхожу в раш, забываю про комиты. И в конце дня у меня 5 коммитов по 2 строки кода каждый и 1 последний на ~200 строк)))
Доброго дня, Сергей! Спасибо большое за ваши видео, они замечательны и полезны. Что касается чистоты кода, я думаю, многие согласятся с тем, что чем больше ваших видео выходит по этой теме, тем лучше. Поэтому продолжайте, пожалуйста, в том же духе, расскажите и объясните (у вас это здорово получается) все, что знаете. Большое спасибо за все видео на канале, это сверхполезно как для начинающих, так и для опытных специалистов в программировании. С нетерпеньем ждем новых видео!
Один из самых шикарных моих комментариев - когда один объект перекладывали в другой и вместо номера документа клали текущую дату. Я прямо специально написал - "Нет, это не ошибка, здесь действительно надо менять номер документа на текущую дату, согласно письму ФНС номер такой-то". Чтобы при рефакторинге никто этот кусочек не выпилил со словами - "а чего это они тут навертели".
Как правильно писать комментарии в коде? В одной компании говорят пиши "так", в другой пиши "не так". Справа советуют - 30% (цифру придумайте сами) от общего кода. Слева злой амбициозный тимлид говорит - ноу комментс, тру профи всё и так поймет за секунды (были и такие самодуры). Немчинский дает советы - хорошие по делу, много советов. И другие программисты дают советы... Как уже говорилось, есть IDE которые скрывают определенные комментарии. legal и прочие блоки-регионы (VS). Осталось добавить опцию - не показывать комментарии. Вот вообще. И все будут счастливы. Хочешь - смотри, не хочешь - скрой и смотри чистый код. Всё для тебя. (И тут Остапа понесло...) Но так ведь нельзя верно? А вдруг? А вдруг там написано что то важное в комментарии, а в другом нет? А давайте введем уровни комментариев! Уровень вывода ошибок и его настройка (как в PHP) есть. Так и с комментариями сделаем. Маркируй важный коммент одним способом, а не важный другим. Ну тогда и систему маркировки сделаем. Когда и что маркировать. Книжку напишем. Ролики снимем. Пару систем комментариев придумаем. А может и паттернов? И будем долго спорить чья система лучше. А программа - да и фиг с ней. У нас тут комментарии, паттерны, ООП, гит, солид, тимлид, джун, фреймворки всякие, дженкинс, тесты, докер, девопс (полусисадмин, полупрограмист, полутестировщик на полузарплате?), скрум, джира в которой дедлайн. А программа - да и фиг с ней. Не мешайте нам играть в IT. Не до программы.
а в несовременной идэешке мне иногда реально надо, для себя, хотя бы на время отладки, пояснить чей это конец ( энд; ). Тут никакого рефакторинга нет и ничё не уедет. И не схлопывается, т.к. это простенький турбо паскаль, а не какойнибудь лазарус. Точно не как в дотнете.
Что то мне подсказывает что комментарии из серии "эту строчку добавил Аджаха", это требования местных компаний что бы знать, кому давать по шапке если что. Смысла не очень много но может так привыкли работать
Здравствуйте Сергей! Смотрю вас где-то с полгода. Хорошая и понятная подача, спасибо за контент! Нет ли у вас идеи, после цикла видосов по "Чистый код" сделать цикл по паттернам?
блииииин... мне так стыдно теперь ахах, я на гитхаб залил свою прогу и там все комментарии реально по типу "капитан очевидность", в коде где происходит импорт, я сверху написал комментарий: импорт модулей - просто гений мать вашу...
По разному бывает. Бывает болото. А бывает, что за 10 лет много разного сделано и команды несколько раз перегруппировались. И есть офигенное развитие. Но болото чаще.
Работала как-то на проекте, где были "высокие стандарты кода и комментирования", но всё время не оставляло ощущение, что гребу лопатой кучу удобрений. Вопросы отпали, когда наткнулась на комментарий: // ToDo удалить ..., когда ... /* блок кода */
Приходилось ковыряться в прошивке на ассемблере, где из 8000 строк кода в общей сложности около 2000 были закомменчены. Асм и так не самый легко читаемый язык, а тут ещё и такое.
по поводу javadoc. По мне он не нужен и для многих public методов. Если методы используются той же частью системы, где находятся классы, где определены эти методы - по мне это тоже лишнее. javadoc нужен или для интерфейсов, которые будут использоваться в другой системе(javadoc для вашего API) или для методов, которые предосталвяют интерфейс другим частям вашей системы.
Комментарии "что внутри" в легаси с Active Record, где к этой базе, кроме твоего проекта ходят еще 10, это единственное спасение. На одном проекте в таблице были поля reason_cancel и cancel_reason: одно тип причины отказа (число), а второе - детальное описание. Спустя 10 проходов мимо этиэ двух полей пришлось всунуть комментарии к phpdoc-у с описанием этих полей.
Шах и мат тем неучам, которые выпиливают комментарии, никогда их не пишут и считают, что самодокументируемого кода достаточно. Десяток причин, почему комментарии нужны. А те, кто их не пишет, делают это спецом, чтобы никто не разобрался. Комментарии пишутся в первую очередь для того, чтобы сам или другой быстро могли разобраться в коде. Чтение кода происходит гораздо чаще его написания. Каждый самовлюблённый прогер старается не рассказывать, что он тут наг...кодил, чтобы его не подсидели. С одним пунктом не согласен. Можно закомментировать ненужный код и отправить его в коммит. Например, вы писали код, который прямо сейчас свою работу не выполнил, но планируете через месяц вернуться к задаче. Либо код не выполнил работу, потому что библиотека с граблями, вы к ней обращались таким способом и получили неверный результат. Тогда можно закомментировать код для себя или других, что задача решалась так, попробуйте другим способом, этот не подходит.
Спасибо большое за выпуски) Я хотел поинтересоваться, как можно научиться быстрее читать и понимать чужой код? (Не нашёл такой выпуск, если такой выпуск есть, тыкните пожалуйста ссылкой)
Я качу послушать про .net, желательно с сопоставлением технологий, конкретно спринга (релаизации di контейнеров например), где что удобнее, лучше и т.д. Насколько я знаю в .net отсутствуют аннотации, там нет аналога Autowired и прочих удобных аннотаций, которые сильно упрощают написание кода. Хотелось бы услышать ваше мнение касательно этого
У меня был случай, когда после удаления одного комментария программа переставала компилироваться. Но там любые изменения (даже правильные с точки зрения синтаксиса языка) приводили к такому результату.
В процесе обучения приучил себя присать коменты везде и всегда, недавно попал на первую работу(джава) и мне запретили писать коментирии в коде, абсолютно. Аргументируют тем что коментарии всеравно теряются в процесе потдержки и тем что написание коментов розхолаживает ( между сделать код понятнее и просто написать комент все выберают написать комент). Как вам такой подход ??
Здравствуйте, расскажите пожалуйста,как узнать какие лучше функции использовать для программирования на c#, например делать кортеж или просто разбить на малые части , как вообще узнать какие функции больше грузят процессор? Можно ли где то прочитать информацию по этому поводу?
Принято ли большие классы размечать комментариями на блоки? Эта группа методов отвечает за интерфейс (образно), эта группа методов отвечает за взаимодействие с какими-нить API, эти что-то еще делают. Очень удобно, когда скроллишь большой класс вверх-вниз. IDE позволяют быстро найти искомый метод, но все же.
По поводу комментариев в приватном методе, не согласен, например есть приватный метод, который вычисляет какое то значение либо тот же regexp использует, почему нельзя написать ему пояснение, чтобы легче было понять что это и для чего
Назрел вопрос: часто проект на который ты приходишь, мягко говоря, не свежий. Например на Java 7 и переход на Java 8 только в планах и непонятно когда. Как лучше работать с плохо написанным спагетти легаси кодом? Спасибо за контент!)
После этого видео у меня сфоримровалось довольно запутанное понимание о комментировании. В книге Стива Макконнелла "Совершенный код" призывают использовать псевдокод перед планированием метода, и описывать метод до его определения, то есть использовать Javadoc или его альтернативы, там приводится пример хорошо самодокументированного кода, но все равно комментируется каждая строка, а все ещё Сергей Немчинский призывает не писать комментарии когда код и так понятен, и что мне делать? Или это я не так понял кого то, или кто-то призывает к неправильному комментированию 👍
Sergey Nemchinskiy, добрый вечер. С чего начать самообучение на практике, Apache или Nginx ??? Обзавелся VPS хостингом и потихоньку изучаю linux что бы суметь разместить первое веб приложение на Java своими руками. В интернете про выбор того или иного, много разного пишут, что только усложняет выбор.
❗❗Программисты, которые пишут на ООП языках, обращаюсь к вам, расширяйте свои знания! Регистрируйтесь на anvanced лекцию, которая состоится уже 29 августа в 15:00. Мы рассмотрим самые популярные паттерны GoF и разыграем 3 места на мой авторский тренинг GRASP & GOF Design Patterns. Присоединяйтесь к нам, регистрируйтесь - go.foxminded.ua/3yPdTeW
Не прочитав название до конца, уже решил, что Сергей Немчинский начал учить своих подписчиков писать комментарии к своим видео
Ваш, кстати, очень даже ничего😁
Видео описывает правильное комментирование кода, чтобы тот был читаем. Пишите «зачем мы это делаем», а не «что мы делаем». - вот вроде правильный коммент к видео
@@aleksandrageev7960 это из серии капитан очевидность)
Как все таки хорошо что вас по прежнему зовут Сергей Немчинский))). Я каждый раз с опаской открываю видео и боюсь услышать что вас зовут как то по другому
Он еще говорил раньше ,что он с большим опытом :-)
теперь в конце видео) можно улучший эту фишку, теперь неожиданно посреди видео Сергей будет говорить свою фразу)
Шутки шутками, а Немчинский не начал рассказ от Адама и Евы. Ваши опасения не безосновательны))
@@andyvoice Вопрос про комментирование в embedded: частенько имеется большой участок кода, где регистры периферии заполняются конфигурационными значениями, или проверяются флаги системных событий. При этом даже из названий применяемых define не всегда понятно - что именно здесь происходит. Получается такой код все же допускает сквозное комментирование?
это еженедельный бессмысленный комментарий-фича)))
У нас как-то был комментарий в коде:
"А ключ от АПИ возьмите у Раджи". Раджи на проекте не было.
"Take API key from Raji".
ахахаха
Индусы умеют шутить 😂😂😂😂😂
Зита и Гита любят жабу. Пытался я как то добиться хоть чего то от поддержки хьюлета паккарда, бесполезное дело
может это раджа из ряда визирь, раджа, проджект менеджер?)
Это пизнес конечно, ору)
«Это цикл» лучший комментарий, что я когда то видел
Я бы послушал про "индусов" их код и особенности )))
А меня за это не забанят? :)
Кстати, работаю с индусам (вся команда из Индии), и они пишут так же, как и все. Не сказал бы, что их код чем-то отличается от остальных. В целом очень шарящие и позитивные ребята, короче :)
@@SergeyNemchinskiy Можна про умовних "індусів", тобто яких помилок програмісти (початківці і не дуже) найчастіше припускаються у своєму коді. З вашого досвіду, звичайно
@@SergeyNemchinskiy До речі, було б непогано в якості прикладу наводити скріни тих помилок, про які ви розповідаєте. Це, звичайно, в дусі "капітан очевидність", але, на мою думку, було б дуже наглядно і краще б запам’ятовувалося
@@sampleusername по-разному бывает. У нас например на проекте были типичные стереотипные индусы) Советую поработать с ними, интересный экспириенс)
Спасибо! тема интересная и, в какой-то мере, универсальная для разных языков.
@@universum9876 ага😂
Бонус+ коммент для продвижения)) да и для автора приятен фидбек
и он прав :) Спасибо!
Очень интересно. Хотелось бы посмотреть маленькие наглядные примеры правильного кода
Единственный канал, где я не проматываю рекламу)
очень приятно :)
Кстати, да. Согласен)))
И... Это точно)
+
Привычку к написанию капитанских комментариев часто формируют в учебных заведениях, заставляя студентов комментировать чуть ли не каждый шаг. Ох как меня это бесило. Сколько я срался с преподом из-за этого...
- Зачем комментировать очевидные вещи?
- Это для тебя они очевидные, а для других - нет!
Да, у нас тоже такая отбитая совковая преподша вела программирование. Требовала комментарии в каждой строчке, и обязательно на английском, но сама при этом английский не знала. Один чувак на потоке сдавал ей лабы с текстами группы Slayer в комментариях.
int AAAAAAAAAAAAAAA; //Angel Of Death!
@@alexlightweight Вот не зря Сергей так топит за обучение с ментором: без критики от профессионала из отрасли легко уйти не туда (а то и вовсе не дойти).
ИМХО, разработка хотя бы вдвоём по качеству кода, скорее всего, будет на голову выше разработки в одно лицо. А одному можно сидеть хоть 10 лет и не вырасти вообще.
@@alexlightweight Мне почему-то кажется, что если код настолько корявый, то и комменты были бы не сильно понятнее)) Но лучше, конечно, хоть какое-то объяснение, чем никакого.
@@alexlightweight У меня на самой первой работе была похожая ситуация. Ушёл оттуда, ибо было тяжело как мне с этими людьми, так и им со мной (я хоть и был без опыта, но теоретически уже понимал такого рода вещи).
Они были намного старше, учились программировать где-то в восьмидесятые или начале девяностых, когда о хороших практиках программирования вообще мало кто слышал. И сейчас их уже не переучишь.
Да и им это не интересно: для них-то всё работает, заказчик деньги платит, значит имеют право говнокодить как хотят (ну а я, соответственно, имею право поискать другое место работы, где взгляды программистов будут больше совпадать с моими).
Очень полезная информация! Спасибо!
Было бы здорово после всех серий показать рабочий пример со всеми затронутыми темами и выложить его на git как шпаргалку ;)
Хоть и смотрел ещё давно фулл лекцию по мытью кота, но эта серия - пушка, спасибо, продолжайте!
фулл с Немчинским))) звучит-то как)))
Очень интересная тема! Жутко полезно, давно хотел найти развернутое пособие "Что такое хорошо, а что такое плохое" по комментариям. Сергей, так держать!
21:21 В языках с препроцессором (C/C++ и некоторые другие) комментарий о закрытии препроцессорного блока #if/#ifdef может выручать, если размер такого блока изрядный, или есть приличная вложенность подобных блоков. Просто облегчает поиск его окончания. Причём полезно дублировать в комментарии всю конструкцию изначального условия.
#if SOME_DEFINE || OTHER_DEFINE > 0
... 100500 строк.
#ifdef DEBUG
...
#endif // #ifdef DEBUG
...
#else // #if SOME_DEFINE || OTHER_DEFINE > 0
... 500100 строк.
#endif // #if SOME_DEFINE || OTHER_DEFINE > 0
Обоснование: препроцессор это как бы "надязык", его конструкции переплетаются с кодом основной структуры программы, и зачастую не имеет отступов (так как это уменьшает наглядность кода или же такие отступы вступают в конфликт с отступами самого языка).
Qt автоматом добавляет такой коммент к концу Header guard-а для новых файлов.
А для визуализации вложенности они у себя в коде отделяют пробелами # и команду препроцессору:
#ifndef FOO
# ifndef BAR
# define BAR
# endif
#endif
Но всё-равно препроцессор - это адский ад, сильно замусоривает код.
Когда нужно решить задачу в очень сжатый срок - приходится писать говно, и оставлять для себя на будущее комментарии - что и как потом переделать. Так что без TO DO вообще никуда
Доброго дня. Классный цикл лекций. Для прошареных наверно известные истины, для остальных же, хорошая подача. Интересно про взаимодействие в команде. Например фронт/бэк. Как разговаривать если ты делаешь систему, которая зависит от другой системы.
SFsdsrsd
Тема интересная, Сергей. Продолжайте, пожалуйста. Сам студент и смотрю с удовольствием.
я не понимаю холивара вокруг комментов. Почему вдруг это стало такой обсуждаемой на каждом углу проблемой?
Ну хороший код и не нужны комменты - красота, а если комменты есть - еще лучше.
Я даже в собственном коде, который хорошо понимаю - оставляю комменты в первую очередь для себя, потому что мне проще врубиться в какие-нибудь алгоритмы фильтрации массивов, ключей и прочих циклов и шаманства, прочитав комменты, чем каждую строчку кода разбирать и пытаться вспомнить почему именно так делается и почему на входе получается один массив, а на выходе другой. За-то когда читаю чужой код с такой же магией - матерей разрабов в кино вожу, потому что им было лень написать 3 слова к своей конструкции и я должен тратить порой по нескольку часов, чтобы отдебажить каждую строчку кода и понять где собака зарыта.
Просто есть шаблонный код, который ничего особого не выполняет и ты одним взглядом понимаешь что он выполняет, а бывают сложные алгоритмы, которые не с первого взгляда очевидны что они выполняют, как ты не упрощай код и как не называй ты те переменные, почему бы не оставить пару слов о том что выполняется в коде ниже. Я бывает в особых случаях даже каждую строчку комментирую в цикле, потому что было не раз такое, что возвращался к своему же коду, видел "ошибку" или какое-то "ненужное условие", удалял его, а потом ловил багулину, потому что оказывается оно там нужно было. После пары таких раз - решил класть на все эти ваши стандарты по клинкоду и писать так, чтобы любой индус разобрался. Особенно это актуально на старых и загаженных проектах, где все держится на подпорках из говна и палок. Это может на ваших там ААА проектах все чики-пуки, по всем современным стандартам в лице фреймворков, мне к сожалению такие видеть не доводилось.
Раньше смотрел WOT блоггеров, сейчас это. Прям в другие места мозга нажимает. Полезные видео.
спасибо, очень полезно, особенно для начинающих. мне уже давно советовали прочитать чистый код, а так слушая, тем более с примерами, на мой вкус намного яснее и понятнее становиться!!!
CheckOplata - лучший комментарий из тех, что видел
ахаха
Англо-український суржик латинкою!!!!! Аааааааааа
комментарий? больше похоже на название класса (если говорить про джаву)
У меня коллега любит так методы и классы называть, пока никто не видит. А ты потом думай, что значит MessagePresenterTut. Что за Tut, нахера оно нужно и не скрывается ли за ним какой-то сакральный бизнес-смысл?
@@alexeymurnikov1413 Tut? Мейби сокращение как Dto🤷♂️
Спасибо! Ещё хотелось бы именно от Вас о CI/CD услышать )
Я так курсач писал. "Нужно много коментов" говорили они, "прибавление единицы" писал я
У меня на одном проекте в коде был комментарий: "Аня, удали этот ужас"))) Но сам я тоже этот ужас не удалил)) Так и живет наверно там))))
спасибо! интересно, а главное по существу и с примерами из практики )
Сергей, спасибо за Ваш труд! Всё полезно, познавательно и практично👍 Жду новых выпусков! Успехов Вам!
Этот курс лекций очень интересен! Сергей продолжай :)
Спасибо, наш дорогой Сергей Немчинский 😄
Оказывается я правильные комменты в коде пишу. По поводу комментария "Это мост". Часто видел у новичков коммент типа "Цикл for начало/конец". Блин я и без коммента понимаю что это while :). Про закомментированный кусок кода, раньше оставлял, авось пригодится, реально ни разу не нужен если ты его заменил на другой работающий код.
Нас, когда мы были студентами, заставляли комментировать языковые конструкции, типа for(...)//цикл от.. до..
А выделение начала-конца блока я и сам, будучи совсем зелёным, делал, ибо тогда ИДЕшки не умели в нормальную подсветку (кто помнит Delphi - привет).
@@0imax Нас при обучении, ни кто не заставлял комментировать вообще. Все комменты на свое усмотрение. Вот обучение было веселое: 1 курс - QBasic, 2- Turbo Pascal, 3 - Borland C++, 4 - Были разные предметы на которых каждый препод свой язык толкал и получилось что параллельно преподавались (Delphi, Visual Basic, Visual C++ MFC), 5 - только Visual Basic, хотя препод и не против если на C# или Java все сдашь.
Ладно. Тут понятно откуда ноги растут. Но не понятно от куда такие же ноги у тех кто сам пытается научиться программированию. Но сомневаюсь, что везде так преподают.
Был как-то коментарий //какая же е..тая CMS как же от неё >|
Для закоментированного кода есть специфический кейс. Когда просят вырубить фичу. Меняется программист. Просят врубить фичу. С ненулевой вероятностью новый программер напишет ее заново, если она не закоментарена, а удалена.
Теперь я знаю как написать чтобы мой код не трогали. Хотя смысла 0, но знаю.
Закомментированый код - офигенная штука, когда ты - веб дев, сидишь на одном проекте годами и тебя периодически просят воткнуть на морде какой-то временный функционал. Или временно отключить какой-то функционал.
интересует послушать опыт о
1. разбиение на отдельные модули
2. про разделение на слои абстракций
Сергей, спасибо за очередную полезную лекцию!
Было бы по очень интересно послушать про хорошие и плохие коммиты.
А то когда начинаю работать делаю коммит под каждый чих, а потом вхожу в раш, забываю про комиты. И в конце дня у меня 5 коммитов по 2 строки кода каждый и 1 последний на ~200 строк)))
і про назви комітів
Доброго дня, Сергей! Спасибо большое за ваши видео, они замечательны и полезны. Что касается чистоты кода, я думаю, многие согласятся с тем, что чем больше ваших видео выходит по этой теме, тем лучше. Поэтому продолжайте, пожалуйста, в том же духе, расскажите и объясните (у вас это здорово получается) все, что знаете. Большое спасибо за все видео на канале, это сверхполезно как для начинающих, так и для опытных специалистов в программировании. С нетерпеньем ждем новых видео!
Отличное видео! Хоть оно и предназначается для новичков, но у меня частенько возникает желание отправить его некоторым из своих коллег))
Ещё бы было интересно послушать про хорошие и плохие сообщения к коммитам в гите
Один из самых шикарных моих комментариев - когда один объект перекладывали в другой и вместо номера документа клали текущую дату. Я прямо специально написал - "Нет, это не ошибка, здесь действительно надо менять номер документа на текущую дату, согласно письму ФНС номер такой-то". Чтобы при рефакторинге никто этот кусочек не выпилил со словами - "а чего это они тут навертели".
По code smells было бы тоже интересно послушать
тема. Спасибо за совет
// Супер интересный курс, надеюсь по данной теме ролики еще будут.
9:54 предупреждение о последствиях: если кто-то сломает этот код, придет пм и сломает кодеру пальцы))
баш на баш_))))))
Как правильно писать комментарии в коде?
В одной компании говорят пиши "так", в другой пиши "не так". Справа советуют - 30% (цифру придумайте сами) от общего кода. Слева злой амбициозный тимлид говорит - ноу комментс, тру профи всё и так поймет за секунды (были и такие самодуры). Немчинский дает советы - хорошие по делу, много советов.
И другие программисты дают советы...
Как уже говорилось, есть IDE которые скрывают определенные комментарии. legal и прочие блоки-регионы (VS).
Осталось добавить опцию - не показывать комментарии. Вот вообще. И все будут счастливы.
Хочешь - смотри, не хочешь - скрой и смотри чистый код. Всё для тебя.
(И тут Остапа понесло...)
Но так ведь нельзя верно? А вдруг? А вдруг там написано что то важное в комментарии, а в другом нет? А давайте введем уровни комментариев!
Уровень вывода ошибок и его настройка (как в PHP) есть. Так и с комментариями сделаем.
Маркируй важный коммент одним способом, а не важный другим. Ну тогда и систему маркировки сделаем. Когда и что маркировать.
Книжку напишем. Ролики снимем. Пару систем комментариев придумаем. А может и паттернов?
И будем долго спорить чья система лучше.
А программа - да и фиг с ней.
У нас тут комментарии, паттерны, ООП, гит, солид, тимлид, джун, фреймворки всякие, дженкинс, тесты, докер, девопс (полусисадмин, полупрограмист, полутестировщик на полузарплате?), скрум, джира в которой дедлайн.
А программа - да и фиг с ней. Не мешайте нам играть в IT. Не до программы.
Закоментированные комментарии это по-моему лучшее, что может быть
а в несовременной идэешке мне иногда реально надо, для себя, хотя бы на время отладки, пояснить чей это конец ( энд; ). Тут никакого рефакторинга нет и ничё не уедет. И не схлопывается, т.к. это простенький турбо паскаль, а не какойнибудь лазарус. Точно не как в дотнете.
Очень нужная серия лекций по клин код, спасибо!
Для тех кто в теме просто огонь)))
Огромное спасибо, Сергей, за полезный ролик!
Спасибо Эйр Астану. Я рад.
Что то мне подсказывает что комментарии из серии "эту строчку добавил Аджаха", это требования местных компаний что бы знать, кому давать по шапке если что. Смысла не очень много но может так привыкли работать
Всё интересно. С удовольствием послушал бы о профилировании приложений java
Здравствуйте Сергей! Смотрю вас где-то с полгода. Хорошая и понятная подача, спасибо за контент! Нет ли у вас идеи, после цикла видосов по "Чистый код" сделать цикл по паттернам?
@@universum9876 Извиняюсь за свой русский)
Есть уже такое от Сергея - целая серия SOLID и других паттернов
у меня есть тренинг по паттернам: foxminded.com.ua/grasp-gof-design-patterns-advanced-on-line-course/
У него ещё есть плейлист, с записями лекций, по паттернам, звук очень плохой, но содержание полезное
Что касается журнала изменений, я обычно его полностью вижу через гит, прям в Идееке
Самый полезный комментарии в коде:
Никто не знает почему оно не работает, но если удалить - не работает)))
Хотел оставить комментарий, но понял, что он будет из разряда нежелательных ... ☺️
отличное видео, правил комменты к своим автотестам прямо по ходу видео :)
отлично :)
Неоднократно включаю видео, играет на фоне, и допиливаю проект в IDE)
блииииин... мне так стыдно теперь ахах, я на гитхаб залил свою прогу и там все комментарии реально по типу "капитан очевидность", в коде где происходит импорт, я сверху написал комментарий: импорт модулей - просто гений мать вашу...
Здравствуйте, Сергей. Как относитесь к "синьерам", которые сидят 10 лет на одном проекте?
Уходи уже с этого проекта, Виталий :)
@@BaJIePkA86 ахаха, не, я джун
По разному бывает. Бывает болото. А бывает, что за 10 лет много разного сделано и команды несколько раз перегруппировались. И есть офигенное развитие. Но болото чаще.
Очень хороший и нужный курс!!! Спасибо!!!
Золотое правило писания комментарии, просто и эффективно
Как на счет ascii art в коде?
Это про Spring чтоле? ))
Работала как-то на проекте, где были "высокие стандарты кода и комментирования", но всё время не оставляло ощущение, что гребу лопатой кучу удобрений. Вопросы отпали, когда наткнулась на комментарий:
// ToDo удалить ..., когда ...
/* блок кода */
Спасибо за лекции!
прослушал все видосы по клин-код и понял, что подтираю говнокод говнокодом(разрабатываю под вордпресс)
это нормально :)
это называется "клин клином вышибать")))
про Патрика Свейзи... улыбнуло)
Комментарии только по паблику - это плохая идея. Могут быть много сложных приватных вещей, требующих объяснений.
Да неее, никогда такого не видел.
Негативно отношусь к PHPDoc т.к. методы становятся длиннее в два раза почти, а по факту к описанию метода через IDE я обращаюсь крайне редко...
я бывало оставлял комменты матом, ну если сильно пригорает )) иногда в комментах оставлял послания для потомков, шоб сильно не ругали ))
тема супер! поменьше о высоком, побольше о нужном - идеально.
серьёзно? понимание когда нужны или не нужны комменты - это что-то нужное?
Спасибище огромное!
23:23 - эх, наверное многие грешили этим делом, не тысячи строк конечно, но всё же...
Приходилось ковыряться в прошивке на ассемблере, где из 8000 строк кода в общей сложности около 2000 были закомменчены. Асм и так не самый легко читаемый язык, а тут ещё и такое.
по поводу javadoc. По мне он не нужен и для многих public методов. Если методы используются той же частью системы, где находятся классы, где определены эти методы - по мне это тоже лишнее. javadoc нужен или для интерфейсов, которые будут использоваться в другой системе(javadoc для вашего API) или для методов, которые предосталвяют интерфейс другим частям вашей системы.
///
/// Так выглядит "Жаба док" в C#
///
void Start()
thanks so much
😀
/**
Хорошее видео
*/
Мое правило во время кодревью простое: "Ты написал comment - код говно"
good video
Комментарии "что внутри" в легаси с Active Record, где к этой базе, кроме твоего проекта ходят еще 10, это единственное спасение. На одном проекте в таблице были поля reason_cancel и cancel_reason: одно тип причины отказа (число), а второе - детальное описание. Спустя 10 проходов мимо этиэ двух полей пришлось всунуть комментарии к phpdoc-у с описанием этих полей.
Шах и мат тем неучам, которые выпиливают комментарии, никогда их не пишут и считают, что самодокументируемого кода достаточно. Десяток причин, почему комментарии нужны. А те, кто их не пишет, делают это спецом, чтобы никто не разобрался.
Комментарии пишутся в первую очередь для того, чтобы сам или другой быстро могли разобраться в коде. Чтение кода происходит гораздо чаще его написания. Каждый самовлюблённый прогер старается не рассказывать, что он тут наг...кодил, чтобы его не подсидели.
С одним пунктом не согласен. Можно закомментировать ненужный код и отправить его в коммит. Например, вы писали код, который прямо сейчас свою работу не выполнил, но планируете через месяц вернуться к задаче. Либо код не выполнил работу, потому что библиотека с граблями, вы к ней обращались таким способом и получили неверный результат. Тогда можно закомментировать код для себя или других, что задача решалась так, попробуйте другим способом, этот не подходит.
Спасибо большое за выпуски)
Я хотел поинтересоваться, как можно научиться быстрее читать и понимать чужой код? (Не нашёл такой выпуск, если такой выпуск есть, тыкните пожалуйста ссылкой)
Я качу послушать про .net, желательно с сопоставлением технологий, конкретно спринга (релаизации di контейнеров например), где что удобнее, лучше и т.д. Насколько я знаю в .net отсутствуют аннотации, там нет аналога Autowired и прочих удобных аннотаций, которые сильно упрощают написание кода. Хотелось бы услышать ваше мнение касательно этого
есть ещё один вид плохих комментариев: пустой todo - нужно что-то сделать, но что и зачем - не указано 🙃
Удалить закомментированный пару лет назад код и через неделю окажется, что он был нужен… так с вещами всегда получается. Вот бы был гит для вещей
1:35 несколько комментариев по поводу комментариев
О том как коментить не кто не где не учат, очень полезное видео, об смысловой нагрузке комментариев даже не задумывался. Спасибо))
У меня был случай, когда после удаления одного комментария программа переставала компилироваться.
Но там любые изменения (даже правильные с точки зрения синтаксиса языка) приводили к такому результату.
В процесе обучения приучил себя присать коменты везде и всегда, недавно попал на первую работу(джава) и мне запретили писать коментирии в коде, абсолютно. Аргументируют тем что коментарии всеравно теряются в процесе потдержки и тем что написание коментов розхолаживает ( между сделать код понятнее и просто написать комент все выберают написать комент). Как вам такой подход ??
Здравствуйте, расскажите пожалуйста,как узнать какие лучше функции использовать для программирования на c#, например делать кортеж или просто разбить на малые части , как вообще узнать какие функции больше грузят процессор? Можно ли где то прочитать информацию по этому поводу?
Сказано побольше, чем у Макконела.
Принято ли большие классы размечать комментариями на блоки? Эта группа методов отвечает за интерфейс (образно), эта группа методов отвечает за взаимодействие с какими-нить API, эти что-то еще делают. Очень удобно, когда скроллишь большой класс вверх-вниз. IDE позволяют быстро найти искомый метод, но все же.
еще одно оправданное применение комментариев - на ютубе, под роликами Сергея Немчинского.
23:23 ЕТО КАК СТАРЬІЙ МАГНИТОФОН НА БАЛКОНЕ - А ВДРУГ ПОНАДОБИТСЯ😂😂😂
По поводу комментариев в приватном методе, не согласен, например есть приватный метод, который вычисляет какое то значение либо тот же regexp использует, почему нельзя написать ему пояснение, чтобы легче было понять что это и для чего
Назрел вопрос: часто проект на который ты приходишь, мягко говоря, не свежий. Например на Java 7 и переход на Java 8 только в планах и непонятно когда. Как лучше работать с плохо написанным спагетти легаси кодом? Спасибо за контент!)
Дизы по видимому ставят программисты из Индии)
Без комментариев!
иронично
Песков в чатике
После этого видео у меня сфоримровалось довольно запутанное понимание о комментировании.
В книге Стива Макконнелла "Совершенный код" призывают использовать псевдокод перед планированием метода, и описывать метод до его определения, то есть использовать Javadoc или его альтернативы, там приводится пример хорошо самодокументированного кода, но все равно комментируется каждая строка, а все ещё Сергей Немчинский призывает не писать комментарии когда код и так понятен, и что мне делать?
Или это я не так понял кого то, или кто-то призывает к неправильному комментированию 👍
Некоторым программистам хочется иногда отрубить руки))
Sergey Nemchinskiy, добрый вечер. С чего начать самообучение на практике, Apache или Nginx ???
Обзавелся VPS хостингом и потихоньку изучаю linux что бы суметь разместить первое веб приложение на Java своими руками. В интернете про выбор того или иного, много разного пишут, что только усложняет выбор.
Забей на апач, вот что сделай на практике