Comments 25
А вам не кажется что код addSetEntry в принципе не должен существовать? Вместе со своим комментарием.
IE 11 тоже не должно существовать, но он существует.
да ничего в нём особо страшного, я поддерживаю и его на webgl игре. За мелкими исключениями всё ок. Правда с DOM работы почти нет, один канвас, гетКонтекст и поехали.
Ослик и боль:
caniuse.com/#search=server%20side%20events
Метро-ослик тоже не поддерживает, кстати говоря.
caniuse.com/#search=server%20side%20events
Метро-ослик тоже не поддерживает, кстати говоря.
А вам не кажется что код addSetEntry в принципе не должен существовать?
Почему нет? Возможно, это просто вырожденный частный случай. А в остальных местах аналогичные вызовы имеют смысл. Не повод ради одного частного случая — ломать всю единообразную систему.
Компиляторы уже много лет как очень умные — в оптимизированном коде вы не найдете этого лишнего вызова call и лишнего движения на стек.
UFO just landed and posted this here
Имхо, иметь стабильные уважительные отношения с коллегами — это часть профессионализма.
Ну представим, вы где-то накосячили (бывает, не спорьте, косячат все).
И 2 вида реакции более опытного коллеги на это:
1) Я конечно знал, что ты жертва ЕГЭ, но чтобы до такой степени говно в продакшн гнать… Ты вообще понимаешь, что пишешь? И где только таких жопоруких рожают?
или
2) Слушай, похоже здесь не при всех условиях отработает.
В первом случае — психология заставит вас не решать проблему по работе, а перейти на личные выпады.
Во втором случае — сделать то, за что собственно вам и платят деньги, — исправить косяк.
Уважительное отношение к коллегам не означает, что вы способны только замалчивать проблему. Напротив, это позволяет всей фирме в целом работать более продуктивно.
А вот это «код м**ацкий, имеет собственное мнение и не боится называть вещи своими именами.» высказанное в прямой не лицеприятной форме — это только для поднятия ЧСВ того, кто оскорбляет, а никак не для решения собственно самой проблемы.
Ну представим, вы где-то накосячили (бывает, не спорьте, косячат все).
И 2 вида реакции более опытного коллеги на это:
1) Я конечно знал, что ты жертва ЕГЭ, но чтобы до такой степени говно в продакшн гнать… Ты вообще понимаешь, что пишешь? И где только таких жопоруких рожают?
или
2) Слушай, похоже здесь не при всех условиях отработает.
В первом случае — психология заставит вас не решать проблему по работе, а перейти на личные выпады.
Во втором случае — сделать то, за что собственно вам и платят деньги, — исправить косяк.
Уважительное отношение к коллегам не означает, что вы способны только замалчивать проблему. Напротив, это позволяет всей фирме в целом работать более продуктивно.
А вот это «код м**ацкий, имеет собственное мнение и не боится называть вещи своими именами.» высказанное в прямой не лицеприятной форме — это только для поднятия ЧСВ того, кто оскорбляет, а никак не для решения собственно самой проблемы.
Когда я пытаюсь разобраться в чужом коде, то личные качества автора — последнее, что меня волнует, так что комментарии, проясняющие личные качества автора — для меня мусор.
Стишок про замену — очень странное решение. Мало того, что код гораздо красочнее говорит о том, что делается, так ещё и стиховую форму распознавать мозгу заметно труднее, чем стандартный порядок слов.
Мне помнится комментарий в C++ коде достаточно распостраненного банковского продукта. «А вот здесь наступаем на дерьмо мамонта». В коде спец workaround. Да, кстати, в движке Quake 1, опубликованном, есть примерно такое — «лечим баг в карте q2u1”, примерно.
бывают куски кода/логики, которые всегда лучше с комментариями:
1. Оптимизации — краткое пояснение аля «это более быстрая версия вот этого», чтобы узабредших душ других программистов не было желания переписать на более простую, но медленную версию. Заодно и понять код будет проще
2. Нетривиальная математика — краткое описание «этот алгоритм делает то-то» или указание (хотя бы) названия алгоритма могут сэкономить много времени читающего. Особенно это актуально когда в алгоритме есть специфичные модификации.
3. Костыли — бывает так, что нет времени/возможности/сиюминутной необходимости сделать хорошо. С комментарием хоть будет понятно на что обратить внимание и что в первую очередь переделывать при работе с этим куском кода
1. Оптимизации — краткое пояснение аля «это более быстрая версия вот этого», чтобы у
2. Нетривиальная математика — краткое описание «этот алгоритм делает то-то» или указание (хотя бы) названия алгоритма могут сэкономить много времени читающего. Особенно это актуально когда в алгоритме есть специфичные модификации.
3. Костыли — бывает так, что нет времени/возможности/сиюминутной необходимости сделать хорошо. С комментарием хоть будет понятно на что обратить внимание и что в первую очередь переделывать при работе с этим куском кода
Использую простое правило: оставляю комментарии в коде там, где они сэкономят мне время когда я буду читать этот код через год, уже разумеется не помня как и почему я его писал и что он делает.
Наткнулся на какой-то баг/костыль/нюанс и потратил время на поиск решения? Оставлю тут комментарий чтобы в следующий раз не искать снова.
Код содержит нетривиальную бизнес-логику, на придумывание которой ушло какое-то время? Оставлю комментарий с кратким описанием алгоритма. Так как 3-4 строчки текста прочитать быстрее и проще, чем читать несколько десятков строк кода, ходить туда-сюда по ссылкам на другие классы и файлы и пытаться понять что оно все делает.
Некачественный legacy код в котором пришлось однажды разобраться? Рефакторить не всегда есть время и не всегда это целесообразно, а вот оставить пару строчек комментария на будущее, если вдруг придется снова сюда заглянуть — это копеечное усилие, экономящее кучу времени в будущем (мне или другому сотруднику).
Я не верю в самодокументирующийся код. «Самодокументирующимся» бывает только абсолютно тривиальный код типа того же «int age = 32;». Сколько-нибудь сложную логику всегда приходится воспроизводить в голове и напрягаться чтобы понять что она делает. И все это вылетает из головы через несколько дней/недель. Зачем тратить на это время и силы каждый раз, если можно один раз написать 2-3 строчки комментария?
Встречал конторы, у которых в вакансиях прямо написано «мы не пишем комментарии, если вы не можете писать понятный без комментариев код, то вы нам не подходите». Не знаю как это должно выглядеть. Либо как трата кучи лишнего времени и умственных усилий чтобы раз за разом понимать что код делает, либо невероятно избыточный код с кучей лишних методов, имена которых по сути выполняют ту же роль что и комментарии, только написаны без пробелов и кэмелкейсом. И то и другое мне не кажется рациональным.
Наткнулся на какой-то баг/костыль/нюанс и потратил время на поиск решения? Оставлю тут комментарий чтобы в следующий раз не искать снова.
Код содержит нетривиальную бизнес-логику, на придумывание которой ушло какое-то время? Оставлю комментарий с кратким описанием алгоритма. Так как 3-4 строчки текста прочитать быстрее и проще, чем читать несколько десятков строк кода, ходить туда-сюда по ссылкам на другие классы и файлы и пытаться понять что оно все делает.
Некачественный legacy код в котором пришлось однажды разобраться? Рефакторить не всегда есть время и не всегда это целесообразно, а вот оставить пару строчек комментария на будущее, если вдруг придется снова сюда заглянуть — это копеечное усилие, экономящее кучу времени в будущем (мне или другому сотруднику).
Я не верю в самодокументирующийся код. «Самодокументирующимся» бывает только абсолютно тривиальный код типа того же «int age = 32;». Сколько-нибудь сложную логику всегда приходится воспроизводить в голове и напрягаться чтобы понять что она делает. И все это вылетает из головы через несколько дней/недель. Зачем тратить на это время и силы каждый раз, если можно один раз написать 2-3 строчки комментария?
Встречал конторы, у которых в вакансиях прямо написано «мы не пишем комментарии, если вы не можете писать понятный без комментариев код, то вы нам не подходите». Не знаю как это должно выглядеть. Либо как трата кучи лишнего времени и умственных усилий чтобы раз за разом понимать что код делает, либо невероятно избыточный код с кучей лишних методов, имена которых по сути выполняют ту же роль что и комментарии, только написаны без пробелов и кэмелкейсом. И то и другое мне не кажется рациональным.
Когда приходится вставлять какой-нибудь хитроизвернутый костыль, оставляю ссылку на багзиллу, где обсуждалась причина появления костыля, с мнениями и обсуждением вариантов.
Это хорошо. Но баг трекеры имеют свойство отмирать. Или код может попасть к тому, у кого нет доступа к баг-трекеру (как самый радикальный вариант — код однажды станет open source).
Поэтому я предпочитаю комментарии либо прямо в коде, либо в коммитах.
Вообще, кстати, иногда помогает сделать git blame на неясном куске кода, чтобы узнать как и зачем он появился. Конечно, это работает только если команда придерживается адекватной политики описания коммитов, а не фигачит патчи типа «Couple of fixes», «More fixes» или «Added new feature to smthing».
Поэтому я предпочитаю комментарии либо прямо в коде, либо в коммитах.
Вообще, кстати, иногда помогает сделать git blame на неясном куске кода, чтобы узнать как и зачем он появился. Конечно, это работает только если команда придерживается адекватной политики описания коммитов, а не фигачит патчи типа «Couple of fixes», «More fixes» или «Added new feature to smthing».
К сожалению не раз встречал ситуацию, когда такие ссылки протухают через несколько лет. Сменили таск-трекер, сменили формат урлов, просто продолбали данные о старых проектах не сделав бекап. Или вообще этот кусок код был скопипащен из другого проекта, сделанного пять лет назад другой компанией, которую наша компания поглотила и затем расформировала, и вся ее инфраструктура давно свернута. Пара строчек прямо в коде — надежнее, а больше редко бывает надо. Даже если там было какое-то серьезное долгое обсуждение, его выжимку можно поместить в комментарий.
Еще полезно оставлять ToDo с описанием того как грамотно исправить проблему. Если на момент создания костыля не хватало ресурсов для рефакторинга.
Зачастую поясняющие комментарии являются признаком плохого кода. Их наличие говорит об излишней сложности кодовой базы. Поэтому старайтесь убирать поясняющие комментарии и упрощать код, потому что «хороший код — самодокументированный».
Полный бред, самодокументируются только действия и они никак не позволяют понять алгоритм — цель, того что делается и зачем. Вот для этого и нужны комментарии: самодокументирующий код позволит понять, что берётся именно напряжение умножается на силу тока и получается третья размерность, но никак не поможет понять почему из двух разных размерностей получилась третья, а комментарий расскажет, что есть закон Ома. Не говоря уже про то, что оптимизировать алгоритмы можно бесконечно и в любой момент, как правило, видны возможные пути улучшения, на которые сразу нет времени, я их тоже прописваю в комментариях, типа можно попробовать то-то. И вообще, за одной строчкой кода, может стоять очень сложный для понимания алгоритм, из какой-нибудь теории чисел, и это никак не может самодокументироваться 4 арифметическими действиями и фактом, что из числа мы получили число.
А бывает еще так:
Подзывает меня наш сеньор, водит мышкой по моей строчке кода и задает вопрос, на который написан ответ в моем комментарии строчкой выше. Я спрашиваю «Did you read my comment?» «No, I don`t care».
Подзывает меня наш сеньор, водит мышкой по моей строчке кода и задает вопрос, на который написан ответ в моем комментарии строчкой выше. Я спрашиваю «Did you read my comment?» «No, I don`t care».
Мантры вроде "Хороший код в комментариях не нуждается" приносят больше вреда чем пользы. Многие побаиваются комментировать проблемные места, рассуждая от противного: "нет комментария, нет и проблемы".
Комментарии — костыль для подпирания скудности языка.
Задачей языков программирования является передача семантики через синтаксис. Чем богаче и выразительнее синтаксис, тем больше семантики (смысла) приходится на строку кода. Не «действий на строку кода», а «смысла». Если ассемблерные инструкции научиться записывать по 100 на строку, то семантические возможности ассемблера не поменяются, хотя по плотности «инструкций на строку» он превзойдёт многие другие языки.
Новые языки программирования расширяют семантические возможности через системы типов данных, трейты, generic'и, реализацию типовых паттернов через кейворды языка.
Задачей языков программирования является передача семантики через синтаксис. Чем богаче и выразительнее синтаксис, тем больше семантики (смысла) приходится на строку кода. Не «действий на строку кода», а «смысла». Если ассемблерные инструкции научиться записывать по 100 на строку, то семантические возможности ассемблера не поменяются, хотя по плотности «инструкций на строку» он превзойдёт многие другие языки.
Новые языки программирования расширяют семантические возможности через системы типов данных, трейты, generic'и, реализацию типовых паттернов через кейворды языка.
Нужны не каменты, а «rationale» — разумное обоснование. И желательно для всех int age = 32;
Иногда попадаются места в документации, где объясняется причины выбранных решений. Но чаще либо бесполезные каменты либо «самодокументированный код». Сидишь смотришь в исходники и думаешь, или автор такой гений, что ты не можешь постичь его творение (понятно, что изначально считаешь автора умней, я же его исходники читаю, а не он мои), или я такой гений, что во всех исходниках мне говнокод мерещится.
Иногда попадаются места в документации, где объясняется причины выбранных решений. Но чаще либо бесполезные каменты либо «самодокументированный код». Сидишь смотришь в исходники и думаешь, или автор такой гений, что ты не можешь постичь его творение (понятно, что изначально считаешь автора умней, я же его исходники читаю, а не он мои), или я такой гений, что во всех исходниках мне говнокод мерещится.
Можно и комментарии для разрядки оставлять:
Заголовок спойлера
Сворачивание комментариев в коде Visual Studio.
Всё-таки «Сворачивание комментариев в Visual Studio Code».
Sign up to leave a comment.
Комментирование кода: хороший, плохой, злой