Как все таки хорошо что вас по прежнему зовут Сергей Немчинский))). Я каждый раз с опаской открываю видео и боюсь услышать что вас зовут как то по другому
@@andyvoice Вопрос про комментирование в embedded: частенько имеется большой участок кода, где регистры периферии заполняются конфигурационными значениями, или проверяются флаги системных событий. При этом даже из названий применяемых define не всегда понятно - что именно здесь происходит. Получается такой код все же допускает сквозное комментирование?
Видео описывает правильное комментирование кода, чтобы тот был читаем. Пишите «зачем мы это делаем», а не «что мы делаем». - вот вроде правильный коммент к видео
Очень интересная тема! Жутко полезно, давно хотел найти развернутое пособие "Что такое хорошо, а что такое плохое" по комментариям. Сергей, так держать!
спасибо, очень полезно, особенно для начинающих. мне уже давно советовали прочитать чистый код, а так слушая, тем более с примерами, на мой вкус намного яснее и понятнее становиться!!!
Кстати, работаю с индусам (вся команда из Индии), и они пишут так же, как и все. Не сказал бы, что их код чем-то отличается от остальных. В целом очень шарящие и позитивные ребята, короче :)
@@SergeyNemchinskiy Можна про умовних "індусів", тобто яких помилок програмісти (початківці і не дуже) найчастіше припускаються у своєму коді. З вашого досвіду, звичайно
@@SergeyNemchinskiy До речі, було б непогано в якості прикладу наводити скріни тих помилок, про які ви розповідаєте. Це, звичайно, в дусі "капітан очевидність", але, на мою думку, було б дуже наглядно і краще б запам’ятовувалося
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 вообще никуда
Привычку к написанию капитанских комментариев часто формируют в учебных заведениях, заставляя студентов комментировать чуть ли не каждый шаг. Ох как меня это бесило. Сколько я срался с преподом из-за этого... - Зачем комментировать очевидные вещи? - Это для тебя они очевидные, а для других - нет!
Да, у нас тоже такая отбитая совковая преподша вела программирование. Требовала комментарии в каждой строчке, и обязательно на английском, но сама при этом английский не знала. Один чувак на потоке сдавал ей лабы с текстами группы Slayer в комментариях.
@@alexlightweight Вот не зря Сергей так топит за обучение с ментором: без критики от профессионала из отрасли легко уйти не туда (а то и вовсе не дойти). ИМХО, разработка хотя бы вдвоём по качеству кода, скорее всего, будет на голову выше разработки в одно лицо. А одному можно сидеть хоть 10 лет и не вырасти вообще.
@@alexlightweight Мне почему-то кажется, что если код настолько корявый, то и комменты были бы не сильно понятнее)) Но лучше, конечно, хоть какое-то объяснение, чем никакого.
@@alexlightweight У меня на самой первой работе была похожая ситуация. Ушёл оттуда, ибо было тяжело как мне с этими людьми, так и им со мной (я хоть и был без опыта, но теоретически уже понимал такого рода вещи). Они были намного старше, учились программировать где-то в восьмидесятые или начале девяностых, когда о хороших практиках программирования вообще мало кто слышал. И сейчас их уже не переучишь. Да и им это не интересно: для них-то всё работает, заказчик деньги платит, значит имеют право говнокодить как хотят (ну а я, соответственно, имею право поискать другое место работы, где взгляды программистов будут больше совпадать с моими).
Сергей, спасибо за очередную полезную лекцию! Было бы по очень интересно послушать про хорошие и плохие коммиты. А то когда начинаю работать делаю коммит под каждый чих, а потом вхожу в раш, забываю про комиты. И в конце дня у меня 5 коммитов по 2 строки кода каждый и 1 последний на ~200 строк)))
Очень полезная информация! Спасибо! Было бы здорово после всех серий показать рабочий пример со всеми затронутыми темами и выложить его на git как шпаргалку ;)
Доброго дня, Сергей! Спасибо большое за ваши видео, они замечательны и полезны. Что касается чистоты кода, я думаю, многие согласятся с тем, что чем больше ваших видео выходит по этой теме, тем лучше. Поэтому продолжайте, пожалуйста, в том же духе, расскажите и объясните (у вас это здорово получается) все, что знаете. Большое спасибо за все видео на канале, это сверхполезно как для начинающих, так и для опытных специалистов в программировании. С нетерпеньем ждем новых видео!
Закомментированый код - офигенная штука, когда ты - веб дев, сидишь на одном проекте годами и тебя периодически просят воткнуть на морде какой-то временный функционал. Или временно отключить какой-то функционал.
У меня коллега любит так методы и классы называть, пока никто не видит. А ты потом думай, что значит 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 все сдашь.
Ладно. Тут понятно откуда ноги растут. Но не понятно от куда такие же ноги у тех кто сам пытается научиться программированию. Но сомневаюсь, что везде так преподают.
я не понимаю холивара вокруг комментов. Почему вдруг это стало такой обсуждаемой на каждом углу проблемой? Ну хороший код и не нужны комменты - красота, а если комменты есть - еще лучше. Я даже в собственном коде, который хорошо понимаю - оставляю комменты в первую очередь для себя, потому что мне проще врубиться в какие-нибудь алгоритмы фильтрации массивов, ключей и прочих циклов и шаманства, прочитав комменты, чем каждую строчку кода разбирать и пытаться вспомнить почему именно так делается и почему на входе получается один массив, а на выходе другой. За-то когда читаю чужой код с такой же магией - матерей разрабов в кино вожу, потому что им было лень написать 3 слова к своей конструкции и я должен тратить порой по нескольку часов, чтобы отдебажить каждую строчку кода и понять где собака зарыта. Просто есть шаблонный код, который ничего особого не выполняет и ты одним взглядом понимаешь что он выполняет, а бывают сложные алгоритмы, которые не с первого взгляда очевидны что они выполняют, как ты не упрощай код и как не называй ты те переменные, почему бы не оставить пару слов о том что выполняется в коде ниже. Я бывает в особых случаях даже каждую строчку комментирую в цикле, потому что было не раз такое, что возвращался к своему же коду, видел "ошибку" или какое-то "ненужное условие", удалял его, а потом ловил багулину, потому что оказывается оно там нужно было. После пары таких раз - решил класть на все эти ваши стандарты по клинкоду и писать так, чтобы любой индус разобрался. Особенно это актуально на старых и загаженных проектах, где все держится на подпорках из говна и палок. Это может на ваших там ААА проектах все чики-пуки, по всем современным стандартам в лице фреймворков, мне к сожалению такие видеть не доводилось.
Как правильно писать комментарии в коде? В одной компании говорят пиши "так", в другой пиши "не так". Справа советуют - 30% (цифру придумайте сами) от общего кода. Слева злой амбициозный тимлид говорит - ноу комментс, тру профи всё и так поймет за секунды (были и такие самодуры). Немчинский дает советы - хорошие по делу, много советов. И другие программисты дают советы... Как уже говорилось, есть IDE которые скрывают определенные комментарии. legal и прочие блоки-регионы (VS). Осталось добавить опцию - не показывать комментарии. Вот вообще. И все будут счастливы. Хочешь - смотри, не хочешь - скрой и смотри чистый код. Всё для тебя. (И тут Остапа понесло...) Но так ведь нельзя верно? А вдруг? А вдруг там написано что то важное в комментарии, а в другом нет? А давайте введем уровни комментариев! Уровень вывода ошибок и его настройка (как в PHP) есть. Так и с комментариями сделаем. Маркируй важный коммент одним способом, а не важный другим. Ну тогда и систему маркировки сделаем. Когда и что маркировать. Книжку напишем. Ролики снимем. Пару систем комментариев придумаем. А может и паттернов? И будем долго спорить чья система лучше. А программа - да и фиг с ней. У нас тут комментарии, паттерны, ООП, гит, солид, тимлид, джун, фреймворки всякие, дженкинс, тесты, докер, девопс (полусисадмин, полупрограмист, полутестировщик на полузарплате?), скрум, джира в которой дедлайн. А программа - да и фиг с ней. Не мешайте нам играть в IT. Не до программы.
блииииин... мне так стыдно теперь ахах, я на гитхаб залил свою прогу и там все комментарии реально по типу "капитан очевидность", в коде где происходит импорт, я сверху написал комментарий: импорт модулей - просто гений мать вашу...
По разному бывает. Бывает болото. А бывает, что за 10 лет много разного сделано и команды несколько раз перегруппировались. И есть офигенное развитие. Но болото чаще.
Что то мне подсказывает что комментарии из серии "эту строчку добавил Аджаха", это требования местных компаний что бы знать, кому давать по шапке если что. Смысла не очень много но может так привыкли работать
Сергей, когда-то поднимался вопрос о том чтобы сделать видео о направлениях психологии и связанной с ними литературе, которыми Вы интересуетесь. Сделаете?
Sergey Nemchinskiy, добрый вечер. С чего начать самообучение на практике, Apache или Nginx ??? Обзавелся VPS хостингом и потихоньку изучаю linux что бы суметь разместить первое веб приложение на Java своими руками. В интернете про выбор того или иного, много разного пишут, что только усложняет выбор.
Приходилось ковыряться в прошивке на ассемблере, где из 8000 строк кода в общей сложности около 2000 были закомменчены. Асм и так не самый легко читаемый язык, а тут ещё и такое.
@@0imax российская фирма Миландр, которая делает микросхемы для военных, за каким-то ... в примерах программирования их микроконтроллеров тоже комментарии пишет по-английски. Не представляю себе американца, который будет разбираться с недоступным ему чипом, отставшим от мирового уровня на 20 лет. Зачем?
@@ФедорНовиков-ф8ы Даташиты на английском, доки на английском, термины на английском. ВСЁ блин на английском. Начинаешь писать на русском - половина слов всё-равно остаются английскими. Пытаешься заменить их на русские - получается длиннющая белиберда :) А миландр ваще "красавцы". Мало того, что по большей части скопипи..ли AVR и PIC, так ещё не всё их добро шьётся стандартными средствами, а на прямых аналогах прошивка от того же AVR работает иначе.
Принято ли большие классы размечать комментариями на блоки? Эта группа методов отвечает за интерфейс (образно), эта группа методов отвечает за взаимодействие с какими-нить API, эти что-то еще делают. Очень удобно, когда скроллишь большой класс вверх-вниз. IDE позволяют быстро найти искомый метод, но все же.
а в несовременной идэешке мне иногда реально надо, для себя, хотя бы на время отладки, пояснить чей это конец ( энд; ). Тут никакого рефакторинга нет и ничё не уедет. И не схлопывается, т.к. это простенький турбо паскаль, а не какойнибудь лазарус. Точно не как в дотнете.
Здравствуйте, расскажите пожалуйста,как узнать какие лучше функции использовать для программирования на c#, например делать кортеж или просто разбить на малые части , как вообще узнать какие функции больше грузят процессор? Можно ли где то прочитать информацию по этому поводу?
Спасибо большое за выпуски) Я хотел поинтересоваться, как можно научиться быстрее читать и понимать чужой код? (Не нашёл такой выпуск, если такой выпуск есть, тыкните пожалуйста ссылкой)
Сергей, добрый день! Какой минимум должен знать java-разработчик на первой работе в области CI/CD (например, про Docker, Openshift, Nexus, Jenkins, Checkmarx и Andible и др.)?
У меня был случай, когда после удаления одного комментария программа переставала компилироваться. Но там любые изменения (даже правильные с точки зрения синтаксиса языка) приводили к такому результату.
В процесе обучения приучил себя присать коменты везде и всегда, недавно попал на первую работу(джава) и мне запретили писать коментирии в коде, абсолютно. Аргументируют тем что коментарии всеравно теряются в процесе потдержки и тем что написание коментов розхолаживает ( между сделать код понятнее и просто написать комент все выберают написать комент). Как вам такой подход ??
Работала как-то на проекте, где были "высокие стандарты кода и комментирования", но всё время не оставляло ощущение, что гребу лопатой кучу удобрений. Вопросы отпали, когда наткнулась на комментарий: // ToDo удалить ..., когда ... /* блок кода */
Я качу послушать про .net, желательно с сопоставлением технологий, конкретно спринга (релаизации di контейнеров например), где что удобнее, лучше и т.д. Насколько я знаю в .net отсутствуют аннотации, там нет аналога Autowired и прочих удобных аннотаций, которые сильно упрощают написание кода. Хотелось бы услышать ваше мнение касательно этого
Назрел вопрос: часто проект на который ты приходишь, мягко говоря, не свежий. Например на Java 7 и переход на Java 8 только в планах и непонятно когда. Как лучше работать с плохо написанным спагетти легаси кодом? Спасибо за контент!)
19:05 _"Было изменено то-то прямо в коде"_ - тут меня обозвали индусом, т.к. не пишу это в GIT. Согласен, что это работает для команд программистов, но не для индивидуальной работы. Я пишу для себя внутренние скрипты на VoIP-сервере для контроля системы или для реализации дополнительного функционала. Зачем мне в этом случае GIT? (c) _на х.й не нужОн мне Ваш GIT?_ 🤬
Комментарии "что внутри" в легаси с Active Record, где к этой базе, кроме твоего проекта ходят еще 10, это единственное спасение. На одном проекте в таблице были поля reason_cancel и cancel_reason: одно тип причины отказа (число), а второе - детальное описание. Спустя 10 проходов мимо этиэ двух полей пришлось всунуть комментарии к phpdoc-у с описанием этих полей.
Сергей, у меня опыт работы джава разработчиком 3 месяца, к нам на проект пришёл парень с опытом больше года, но он даже не знает элементарных вещей, засыпает меня вопросами. Учить его никто не хочет, так как все думают, что он опытный, тимлида в команде нет. Подскажите стоит ли взять его под своё крыло и учить Джаве? Просто думаю если он до этого ничему не научился, то зря только время потрачу
ой какая жиза. ко мне поставили человека с многолетним опытом, когда у меня самого было около 4 мес., какой же диссонанс я ловил, когда читал его говнокод и пытался в голове уложить тот факт, что человек уже почти 3 года кодит и при этом не понимает элементарных вещей...
После этого видео у меня сфоримровалось довольно запутанное понимание о комментировании. В книге Стива Макконнелла "Совершенный код" призывают использовать псевдокод перед планированием метода, и описывать метод до его определения, то есть использовать Javadoc или его альтернативы, там приводится пример хорошо самодокументированного кода, но все равно комментируется каждая строка, а все ещё Сергей Немчинский призывает не писать комментарии когда код и так понятен, и что мне делать? Или это я не так понял кого то, или кто-то призывает к неправильному комментированию 👍
💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/4f3q9bj
Как все таки хорошо что вас по прежнему зовут Сергей Немчинский))). Я каждый раз с опаской открываю видео и боюсь услышать что вас зовут как то по другому
Он еще говорил раньше ,что он с большим опытом :-)
теперь в конце видео) можно улучший эту фишку, теперь неожиданно посреди видео Сергей будет говорить свою фразу)
Шутки шутками, а Немчинский не начал рассказ от Адама и Евы. Ваши опасения не безосновательны))
@@andyvoice Вопрос про комментирование в embedded: частенько имеется большой участок кода, где регистры периферии заполняются конфигурационными значениями, или проверяются флаги системных событий. При этом даже из названий применяемых define не всегда понятно - что именно здесь происходит. Получается такой код все же допускает сквозное комментирование?
это еженедельный бессмысленный комментарий-фича)))
Не прочитав название до конца, уже решил, что Сергей Немчинский начал учить своих подписчиков писать комментарии к своим видео
Ваш, кстати, очень даже ничего😁
Видео описывает правильное комментирование кода, чтобы тот был читаем. Пишите «зачем мы это делаем», а не «что мы делаем». - вот вроде правильный коммент к видео
@@aleksandrageev7960 это из серии капитан очевидность)
У нас как-то был комментарий в коде:
"А ключ от АПИ возьмите у Раджи". Раджи на проекте не было.
"Take API key from Raji".
ахахаха
Индусы умеют шутить 😂😂😂😂😂
Зита и Гита любят жабу. Пытался я как то добиться хоть чего то от поддержки хьюлета паккарда, бесполезное дело
может это раджа из ряда визирь, раджа, проджект менеджер?)
Это пизнес конечно, ору)
«Это цикл» лучший комментарий, что я когда то видел
Спасибо! тема интересная и, в какой-то мере, универсальная для разных языков.
@@UniversumXX ага😂
Бонус+ коммент для продвижения)) да и для автора приятен фидбек
и он прав :) Спасибо!
Очень интересная тема! Жутко полезно, давно хотел найти развернутое пособие "Что такое хорошо, а что такое плохое" по комментариям. Сергей, так держать!
Очень интересно. Хотелось бы посмотреть маленькие наглядные примеры правильного кода
Хоть и смотрел ещё давно фулл лекцию по мытью кота, но эта серия - пушка, спасибо, продолжайте!
фулл с Немчинским))) звучит-то как)))
спасибо, очень полезно, особенно для начинающих. мне уже давно советовали прочитать чистый код, а так слушая, тем более с примерами, на мой вкус намного яснее и понятнее становиться!!!
Этот курс лекций очень интересен! Сергей продолжай :)
Я бы послушал про "индусов" их код и особенности )))
А меня за это не забанят? :)
Кстати, работаю с индусам (вся команда из Индии), и они пишут так же, как и все. Не сказал бы, что их код чем-то отличается от остальных. В целом очень шарящие и позитивные ребята, короче :)
@@SergeyNemchinskiy Можна про умовних "індусів", тобто яких помилок програмісти (початківці і не дуже) найчастіше припускаються у своєму коді. З вашого досвіду, звичайно
@@SergeyNemchinskiy До речі, було б непогано в якості прикладу наводити скріни тих помилок, про які ви розповідаєте. Це, звичайно, в дусі "капітан очевидність", але, на мою думку, було б дуже наглядно і краще б запам’ятовувалося
@@sampleusername по-разному бывает. У нас например на проекте были типичные стереотипные индусы) Советую поработать с ними, интересный экспириенс)
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
Но всё-равно препроцессор - это адский ад, сильно замусоривает код.
Единственный канал, где я не проматываю рекламу)
очень приятно :)
Кстати, да. Согласен)))
И... Это точно)
+
Сергей, спасибо за Ваш труд! Всё полезно, познавательно и практично👍 Жду новых выпусков! Успехов Вам!
Доброго дня. Классный цикл лекций. Для прошареных наверно известные истины, для остальных же, хорошая подача. Интересно про взаимодействие в команде. Например фронт/бэк. Как разговаривать если ты делаешь систему, которая зависит от другой системы.
SFsdsrsd
Один из самых шикарных моих комментариев - когда один объект перекладывали в другой и вместо номера документа клали текущую дату. Я прямо специально написал - "Нет, это не ошибка, здесь действительно надо менять номер документа на текущую дату, согласно письму ФНС номер такой-то". Чтобы при рефакторинге никто этот кусочек не выпилил со словами - "а чего это они тут навертели".
Раньше смотрел WOT блоггеров, сейчас это. Прям в другие места мозга нажимает. Полезные видео.
Когда нужно решить задачу в очень сжатый срок - приходится писать говно, и оставлять для себя на будущее комментарии - что и как потом переделать. Так что без TO DO вообще никуда
Спасибо! Ещё хотелось бы именно от Вас о CI/CD услышать )
Спасибо, наш дорогой Сергей Немчинский 😄
Огромное спасибо, Сергей, за полезный ролик!
спасибо! интересно, а главное по существу и с примерами из практики )
Привычку к написанию капитанских комментариев часто формируют в учебных заведениях, заставляя студентов комментировать чуть ли не каждый шаг. Ох как меня это бесило. Сколько я срался с преподом из-за этого...
- Зачем комментировать очевидные вещи?
- Это для тебя они очевидные, а для других - нет!
Да, у нас тоже такая отбитая совковая преподша вела программирование. Требовала комментарии в каждой строчке, и обязательно на английском, но сама при этом английский не знала. Один чувак на потоке сдавал ей лабы с текстами группы Slayer в комментариях.
int AAAAAAAAAAAAAAA; //Angel Of Death!
@@alexlightweight Вот не зря Сергей так топит за обучение с ментором: без критики от профессионала из отрасли легко уйти не туда (а то и вовсе не дойти).
ИМХО, разработка хотя бы вдвоём по качеству кода, скорее всего, будет на голову выше разработки в одно лицо. А одному можно сидеть хоть 10 лет и не вырасти вообще.
@@alexlightweight Мне почему-то кажется, что если код настолько корявый, то и комменты были бы не сильно понятнее)) Но лучше, конечно, хоть какое-то объяснение, чем никакого.
@@alexlightweight У меня на самой первой работе была похожая ситуация. Ушёл оттуда, ибо было тяжело как мне с этими людьми, так и им со мной (я хоть и был без опыта, но теоретически уже понимал такого рода вещи).
Они были намного старше, учились программировать где-то в восьмидесятые или начале девяностых, когда о хороших практиках программирования вообще мало кто слышал. И сейчас их уже не переучишь.
Да и им это не интересно: для них-то всё работает, заказчик деньги платит, значит имеют право говнокодить как хотят (ну а я, соответственно, имею право поискать другое место работы, где взгляды программистов будут больше совпадать с моими).
Очень нужная серия лекций по клин код, спасибо!
Для тех кто в теме просто огонь)))
Тема интересная, Сергей. Продолжайте, пожалуйста. Сам студент и смотрю с удовольствием.
Сергей, спасибо за очередную полезную лекцию!
Было бы по очень интересно послушать про хорошие и плохие коммиты.
А то когда начинаю работать делаю коммит под каждый чих, а потом вхожу в раш, забываю про комиты. И в конце дня у меня 5 коммитов по 2 строки кода каждый и 1 последний на ~200 строк)))
і про назви комітів
Отличное видео! Хоть оно и предназначается для новичков, но у меня частенько возникает желание отправить его некоторым из своих коллег))
Очень полезная информация! Спасибо!
Было бы здорово после всех серий показать рабочий пример со всеми затронутыми темами и выложить его на git как шпаргалку ;)
Доброго дня, Сергей! Спасибо большое за ваши видео, они замечательны и полезны. Что касается чистоты кода, я думаю, многие согласятся с тем, что чем больше ваших видео выходит по этой теме, тем лучше. Поэтому продолжайте, пожалуйста, в том же духе, расскажите и объясните (у вас это здорово получается) все, что знаете. Большое спасибо за все видео на канале, это сверхполезно как для начинающих, так и для опытных специалистов в программировании. С нетерпеньем ждем новых видео!
У меня на одном проекте в коде был комментарий: "Аня, удали этот ужас"))) Но сам я тоже этот ужас не удалил)) Так и живет наверно там))))
Очень хороший и нужный курс!!! Спасибо!!!
// Супер интересный курс, надеюсь по данной теме ролики еще будут.
отличное видео, правил комменты к своим автотестам прямо по ходу видео :)
отлично :)
Всё интересно. С удовольствием послушал бы о профилировании приложений java
Теперь я знаю как написать чтобы мой код не трогали. Хотя смысла 0, но знаю.
интересует послушать опыт о
1. разбиение на отдельные модули
2. про разделение на слои абстракций
Закомментированый код - офигенная штука, когда ты - веб дев, сидишь на одном проекте годами и тебя периодически просят воткнуть на морде какой-то временный функционал. Или временно отключить какой-то функционал.
CheckOplata - лучший комментарий из тех, что видел
ахаха
Англо-український суржик латинкою!!!!! Аааааааааа
комментарий? больше похоже на название класса (если говорить про джаву)
У меня коллега любит так методы и классы называть, пока никто не видит. А ты потом думай, что значит MessagePresenterTut. Что за Tut, нахера оно нужно и не скрывается ли за ним какой-то сакральный бизнес-смысл?
@@alexeymurnikov1413 Tut? Мейби сокращение как Dto🤷♂️
Спасибо за лекции!
Для закоментированного кода есть специфический кейс. Когда просят вырубить фичу. Меняется программист. Просят врубить фичу. С ненулевой вероятностью новый программер напишет ее заново, если она не закоментарена, а удалена.
Здравствуйте Сергей! Смотрю вас где-то с полгода. Хорошая и понятная подача, спасибо за контент! Нет ли у вас идеи, после цикла видосов по "Чистый код" сделать цикл по паттернам?
@@UniversumXX Извиняюсь за свой русский)
Есть уже такое от Сергея - целая серия SOLID и других паттернов
у меня есть тренинг по паттернам: foxminded.com.ua/grasp-gof-design-patterns-advanced-on-line-course/
У него ещё есть плейлист, с записями лекций, по паттернам, звук очень плохой, но содержание полезное
Спасибище огромное!
Я так курсач писал. "Нужно много коментов" говорили они, "прибавление единицы" писал я
Оказывается я правильные комменты в коде пишу. По поводу комментария "Это мост". Часто видел у новичков коммент типа "Цикл 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 как же от неё >|
я не понимаю холивара вокруг комментов. Почему вдруг это стало такой обсуждаемой на каждом углу проблемой?
Ну хороший код и не нужны комменты - красота, а если комменты есть - еще лучше.
Я даже в собственном коде, который хорошо понимаю - оставляю комменты в первую очередь для себя, потому что мне проще врубиться в какие-нибудь алгоритмы фильтрации массивов, ключей и прочих циклов и шаманства, прочитав комменты, чем каждую строчку кода разбирать и пытаться вспомнить почему именно так делается и почему на входе получается один массив, а на выходе другой. За-то когда читаю чужой код с такой же магией - матерей разрабов в кино вожу, потому что им было лень написать 3 слова к своей конструкции и я должен тратить порой по нескольку часов, чтобы отдебажить каждую строчку кода и понять где собака зарыта.
Просто есть шаблонный код, который ничего особого не выполняет и ты одним взглядом понимаешь что он выполняет, а бывают сложные алгоритмы, которые не с первого взгляда очевидны что они выполняют, как ты не упрощай код и как не называй ты те переменные, почему бы не оставить пару слов о том что выполняется в коде ниже. Я бывает в особых случаях даже каждую строчку комментирую в цикле, потому что было не раз такое, что возвращался к своему же коду, видел "ошибку" или какое-то "ненужное условие", удалял его, а потом ловил багулину, потому что оказывается оно там нужно было. После пары таких раз - решил класть на все эти ваши стандарты по клинкоду и писать так, чтобы любой индус разобрался. Особенно это актуально на старых и загаженных проектах, где все держится на подпорках из говна и палок. Это может на ваших там ААА проектах все чики-пуки, по всем современным стандартам в лице фреймворков, мне к сожалению такие видеть не доводилось.
про Патрика Свейзи... улыбнуло)
Золотое правило писания комментарии, просто и эффективно
По code smells было бы тоже интересно послушать
тема. Спасибо за совет
Как на счет ascii art в коде?
Это про Spring чтоле? ))
Как правильно писать комментарии в коде?
В одной компании говорят пиши "так", в другой пиши "не так". Справа советуют - 30% (цифру придумайте сами) от общего кода. Слева злой амбициозный тимлид говорит - ноу комментс, тру профи всё и так поймет за секунды (были и такие самодуры). Немчинский дает советы - хорошие по делу, много советов.
И другие программисты дают советы...
Как уже говорилось, есть IDE которые скрывают определенные комментарии. legal и прочие блоки-регионы (VS).
Осталось добавить опцию - не показывать комментарии. Вот вообще. И все будут счастливы.
Хочешь - смотри, не хочешь - скрой и смотри чистый код. Всё для тебя.
(И тут Остапа понесло...)
Но так ведь нельзя верно? А вдруг? А вдруг там написано что то важное в комментарии, а в другом нет? А давайте введем уровни комментариев!
Уровень вывода ошибок и его настройка (как в PHP) есть. Так и с комментариями сделаем.
Маркируй важный коммент одним способом, а не важный другим. Ну тогда и систему маркировки сделаем. Когда и что маркировать.
Книжку напишем. Ролики снимем. Пару систем комментариев придумаем. А может и паттернов?
И будем долго спорить чья система лучше.
А программа - да и фиг с ней.
У нас тут комментарии, паттерны, ООП, гит, солид, тимлид, джун, фреймворки всякие, дженкинс, тесты, докер, девопс (полусисадмин, полупрограмист, полутестировщик на полузарплате?), скрум, джира в которой дедлайн.
А программа - да и фиг с ней. Не мешайте нам играть в IT. Не до программы.
9:54 предупреждение о последствиях: если кто-то сломает этот код, придет пм и сломает кодеру пальцы))
баш на баш_))))))
тема супер! поменьше о высоком, побольше о нужном - идеально.
серьёзно? понимание когда нужны или не нужны комменты - это что-то нужное?
thanks so much
😀
блииииин... мне так стыдно теперь ахах, я на гитхаб залил свою прогу и там все комментарии реально по типу "капитан очевидность", в коде где происходит импорт, я сверху написал комментарий: импорт модулей - просто гений мать вашу...
Здравствуйте, Сергей. Как относитесь к "синьерам", которые сидят 10 лет на одном проекте?
Уходи уже с этого проекта, Виталий :)
@@BaJIePkA86 ахаха, не, я джун
По разному бывает. Бывает болото. А бывает, что за 10 лет много разного сделано и команды несколько раз перегруппировались. И есть офигенное развитие. Но болото чаще.
Что то мне подсказывает что комментарии из серии "эту строчку добавил Аджаха", это требования местных компаний что бы знать, кому давать по шапке если что. Смысла не очень много но может так привыкли работать
О том как коментить не кто не где не учат, очень полезное видео, об смысловой нагрузке комментариев даже не задумывался. Спасибо))
Самый полезный комментарии в коде:
Никто не знает почему оно не работает, но если удалить - не работает)))
Закоментированные комментарии это по-моему лучшее, что может быть
Сергей, когда-то поднимался вопрос о том чтобы сделать видео о направлениях психологии и связанной с ними литературе, которыми Вы интересуетесь. Сделаете?
Хотел оставить комментарий, но понял, что он будет из разряда нежелательных ... ☺️
1:35 несколько комментариев по поводу комментариев
Sergey Nemchinskiy, добрый вечер. С чего начать самообучение на практике, Apache или Nginx ???
Обзавелся VPS хостингом и потихоньку изучаю linux что бы суметь разместить первое веб приложение на Java своими руками. В интернете про выбор того или иного, много разного пишут, что только усложняет выбор.
Забей на апач, вот что сделай на практике
23:23 ЕТО КАК СТАРЬІЙ МАГНИТОФОН НА БАЛКОНЕ - А ВДРУГ ПОНАДОБИТСЯ😂😂😂
Что касается журнала изменений, я обычно его полностью вижу через гит, прям в Идееке
Неоднократно включаю видео, играет на фоне, и допиливаю проект в IDE)
23:23 - эх, наверное многие грешили этим делом, не тысячи строк конечно, но всё же...
Приходилось ковыряться в прошивке на ассемблере, где из 8000 строк кода в общей сложности около 2000 были закомменчены. Асм и так не самый легко читаемый язык, а тут ещё и такое.
А про язык для написания комментариев что скажете?
Он вроде в других видео говорил, что английский, т.к. потом редактировать код могут другие люди, из других стран
Я даже в сугубо русскоязычных проектах пишу на английском, даже тудушки. Ибо нефиг.
комментарий должен быть понятным, иначе он не нужен. Нет смысла писать английские комментарии для русскоязычных проектов.
@@0imax российская фирма Миландр, которая делает микросхемы для военных, за каким-то ... в примерах программирования их микроконтроллеров тоже комментарии пишет по-английски. Не представляю себе американца, который будет разбираться с недоступным ему чипом, отставшим от мирового уровня на 20 лет. Зачем?
@@ФедорНовиков-ф8ы Даташиты на английском, доки на английском, термины на английском. ВСЁ блин на английском. Начинаешь писать на русском - половина слов всё-равно остаются английскими. Пытаешься заменить их на русские - получается длиннющая белиберда :)
А миландр ваще "красавцы". Мало того, что по большей части скопипи..ли AVR и PIC, так ещё не всё их добро шьётся стандартными средствами, а на прямых аналогах прошивка от того же AVR работает иначе.
Здравствуйте, расскажите про Code Style.
Принято ли большие классы размечать комментариями на блоки? Эта группа методов отвечает за интерфейс (образно), эта группа методов отвечает за взаимодействие с какими-нить API, эти что-то еще делают. Очень удобно, когда скроллишь большой класс вверх-вниз. IDE позволяют быстро найти искомый метод, но все же.
а в несовременной идэешке мне иногда реально надо, для себя, хотя бы на время отладки, пояснить чей это конец ( энд; ). Тут никакого рефакторинга нет и ничё не уедет. И не схлопывается, т.к. это простенький турбо паскаль, а не какойнибудь лазарус. Точно не как в дотнете.
Здравствуйте, расскажите пожалуйста,как узнать какие лучше функции использовать для программирования на c#, например делать кортеж или просто разбить на малые части , как вообще узнать какие функции больше грузят процессор? Можно ли где то прочитать информацию по этому поводу?
прослушал все видосы по клин-код и понял, что подтираю говнокод говнокодом(разрабатываю под вордпресс)
это нормально :)
это называется "клин клином вышибать")))
Спасибо большое за выпуски)
Я хотел поинтересоваться, как можно научиться быстрее читать и понимать чужой код? (Не нашёл такой выпуск, если такой выпуск есть, тыкните пожалуйста ссылкой)
Сергей, добрый день! Какой минимум должен знать java-разработчик на первой работе в области CI/CD (например, про Docker, Openshift, Nexus, Jenkins, Checkmarx и Andible и др.)?
good video
У меня был случай, когда после удаления одного комментария программа переставала компилироваться.
Но там любые изменения (даже правильные с точки зрения синтаксиса языка) приводили к такому результату.
В процесе обучения приучил себя присать коменты везде и всегда, недавно попал на первую работу(джава) и мне запретили писать коментирии в коде, абсолютно. Аргументируют тем что коментарии всеравно теряются в процесе потдержки и тем что написание коментов розхолаживает ( между сделать код понятнее и просто написать комент все выберают написать комент). Как вам такой подход ??
Сергей, скажите ваше мнение о IBM i (AS400) и RPG. Правда ли умерают или будут жить долго, просто не популярны?
я бывало оставлял комменты матом, ну если сильно пригорает )) иногда в комментах оставлял послания для потомков, шоб сильно не ругали ))
Работала как-то на проекте, где были "высокие стандарты кода и комментирования", но всё время не оставляло ощущение, что гребу лопатой кучу удобрений. Вопросы отпали, когда наткнулась на комментарий:
// ToDo удалить ..., когда ...
/* блок кода */
Мое правило во время кодревью простое: "Ты написал comment - код говно"
Я качу послушать про .net, желательно с сопоставлением технологий, конкретно спринга (релаизации di контейнеров например), где что удобнее, лучше и т.д. Насколько я знаю в .net отсутствуют аннотации, там нет аналога Autowired и прочих удобных аннотаций, которые сильно упрощают написание кода. Хотелось бы услышать ваше мнение касательно этого
Назрел вопрос: часто проект на который ты приходишь, мягко говоря, не свежий. Например на Java 7 и переход на Java 8 только в планах и непонятно когда. Как лучше работать с плохо написанным спагетти легаси кодом? Спасибо за контент!)
Про комментарии есть целая глава в книге Роберта Мартина - Чистый код
так это серия видео как раз по этой книге (в начале вроде даже говорилось)
19:05 _"Было изменено то-то прямо в коде"_ - тут меня обозвали индусом, т.к. не пишу это в GIT. Согласен, что это работает для команд программистов, но не для индивидуальной работы. Я пишу для себя внутренние скрипты на VoIP-сервере для контроля системы или для реализации дополнительного функционала. Зачем мне в этом случае GIT?
(c) _на х.й не нужОн мне Ваш GIT?_
🤬
Что вы думаете про процесс программирования с псевдокодом?
Негативно отношусь к PHPDoc т.к. методы становятся длиннее в два раза почти, а по факту к описанию метода через IDE я обращаюсь крайне редко...
/**
Хорошее видео
*/
Нужная информация.
есть ещё один вид плохих комментариев: пустой todo - нужно что-то сделать, но что и зачем - не указано 🙃
7:35 седьмой способ нужно тут использовать, а не комментарии добавлять 20:10
Комментарии "что внутри" в легаси с Active Record, где к этой базе, кроме твоего проекта ходят еще 10, это единственное спасение. На одном проекте в таблице были поля reason_cancel и cancel_reason: одно тип причины отказа (число), а второе - детальное описание. Спустя 10 проходов мимо этиэ двух полей пришлось всунуть комментарии к phpdoc-у с описанием этих полей.
Сергей, у меня опыт работы джава разработчиком 3 месяца, к нам на проект пришёл парень с опытом больше года, но он даже не знает элементарных вещей, засыпает меня вопросами. Учить его никто не хочет, так как все думают, что он опытный, тимлида в команде нет. Подскажите стоит ли взять его под своё крыло и учить Джаве? Просто думаю если он до этого ничему не научился, то зря только время потрачу
ой какая жиза. ко мне поставили человека с многолетним опытом, когда у меня самого было около 4 мес., какой же диссонанс я ловил, когда читал его говнокод и пытался в голове уложить тот факт, что человек уже почти 3 года кодит и при этом не понимает элементарных вещей...
Ставьте вопрос перед начальством об увеличении ЗП за обучение, или отдельную задачу под списание на это человеко-часов
После этого видео у меня сфоримровалось довольно запутанное понимание о комментировании.
В книге Стива Макконнелла "Совершенный код" призывают использовать псевдокод перед планированием метода, и описывать метод до его определения, то есть использовать Javadoc или его альтернативы, там приводится пример хорошо самодокументированного кода, но все равно комментируется каждая строка, а все ещё Сергей Немчинский призывает не писать комментарии когда код и так понятен, и что мне делать?
Или это я не так понял кого то, или кто-то призывает к неправильному комментированию 👍