Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Я недавно выдрал с проекта кусок архитектурный, который с проблемами. Если хотите — можем поревьюить вместе. Я не знаю, как его улучшить.
С радостью бы что-нибудь поревьюил в свободное время
Так к чему это «бы»? Что-то мешает? :-)
У neovim'а есть пункт, связанный с ревью кода.
А меня прям бесит когда мой код ревьюжат те, чей код недалеко ушел от говнокода. И критика вида: че-та методов многовато и где джавадоки??
Меня как-то ревьюил опытный коллега, который у нас не работает уже. После этого я к ревью не обращался.
-Много двойных пробельных строк;
-Не отбиты пробелами вызовы функций;
-Не все методы с Doxygen комменнтами;
-Названия классов видите ли надо с литеры C начинать, а то вроде как непонятно где класс а где метод (у меня подсветка кода, мне все понятно).
Я спросил его «ну а архитектура-то как?» он «ну я хз, я не понял как оно работает. вроде норм.»
-Много двойных пробельных строк;
-Не отбиты пробелами вызовы функций;
-Не все методы с Doxygen комменнтами;
-Названия классов видите ли надо с литеры C начинать, а то вроде как непонятно где класс а где метод (у меня подсветка кода, мне все понятно).
Я спросил его «ну а архитектура-то как?» он «ну я хз, я не понял как оно работает. вроде норм.»
С претензиями к оформлению и именованиям можно смело слать лесом самого Страуструпа, если в конкретном проекте не утверждены соответствующие стандарты.
Если это официально принятый code style, то претензии по делу — если во всем коде классы с С, а у кого-то нет, читать трудно.
По поводу форматирования у нас поступили просто — есть автоформатёр. Если кто-то написал не так, можно просто текст выделить, нажать пару клавиш и готово, можно ревью по существу делать.
По поводу форматирования у нас поступили просто — есть автоформатёр. Если кто-то написал не так, можно просто текст выделить, нажать пару клавиш и готово, можно ревью по существу делать.
Скорее всего ему было лень пробираться через дебри непривычных наименований. Если все оформлено по гайду, то ничто не мешает смотреть пл существу
Через год-два после того, как я начал учить язык php я понял, что хочется посмотреть как пишут другие. И я полез на киберфорум и стал помогать новичкам решать их проблемы, мысленно критиковал код и наматывал на ус.
Знаете, иногда уже фиг с той красотой кода, понять бы, что это такое я написал год назад…
Тут вот такая загогулина получается, что код обычно делается «красивым» не для того, чтобы от взгляда на него получать эстетическое наслаждение, а чтобы его было проще читать и понимать. Возможно, само слово «красивый» наводит на ложные ассоциации? Попробуйте подставить вместо него слово «читаемый» — и тогда сразу же появится смысл.
Видите ли, когда я открываю конспект по «вышке» от первого курса, а это 93й год, то я впадаю в ступор от того, какой я тогда был умный, если понимал всё это.
Бывает откроешь свой файл, ну вот все переменные понятно называются, методы, классы, всё понятно, но «угадал все буквы, но не смог назвать слово»: ничего не понятно, что, куда, откуда и почему… пока не проследишь, что откуда берётся, пока примерно не восстановишь ход своих _тех_ мыслей, не всегда бывает легко разобраться даже в собственном коде.
Бывает откроешь свой файл, ну вот все переменные понятно называются, методы, классы, всё понятно, но «угадал все буквы, но не смог назвать слово»: ничего не понятно, что, куда, откуда и почему… пока не проследишь, что откуда берётся, пока примерно не восстановишь ход своих _тех_ мыслей, не всегда бывает легко разобраться даже в собственном коде.
Чаще бывает нужно восстановить ход не всех _тех_ мыслей, а только их части. Тогда «красота» кода, в смысле разбиения на блоки, хорошо помогает.
У меня нет в мыслях «разбиения на блоки», уж извините. Я вот сейчас регулярно комментирую изменения, которые в носятся в один модуль созданный мною 4 года назад. Понять тот ужас, который там сейчас имеется я могу с большим трудом, но я ведь всегда могу взять свою оригинальную версию с функциями длиной по 200 строк (не преувеличение… их там, правда, не так много) и поиграться с ней. Ну а потом, уже зная что и где нужно менять я могу и придумать как завернуть всё в ту версию, которая там сейчас используется (на это обычно уходит несколько больше времени, чем на первичное решение проблемы, но так как решение я уже знаю, то это не так страшно).
Зато «красиво»: убрана дубликация кода (как будто эти 100 строк копипаста могли кого-то убить), есть куча комментариев и тестов и т.д. и т.п. Ну и? Кому и зачем всё это было нужно? До сих пор не знаю…
Зато «красиво»: убрана дубликация кода (как будто эти 100 строк копипаста могли кого-то убить), есть куча комментариев и тестов и т.д. и т.п. Ну и? Кому и зачем всё это было нужно? До сих пор не знаю…
Чтобы понять мог другой человек.
В «100 строках копипаста» могли быть ошибки, которые, будучи найденными в, скажем, оригинальном куске кода, останутся в скопированном. Поверьте моему печальному опыту — это не круто, пофиксив такую ошибку, размышлять «Не скопировал ли я куда-нибудь еще этот код?»
Мимо. Там были две идентичные функции для работы с двумя архитектурами. То, что в них могут быть идентичные ошибки и что в большинстве случаев их нужно править одновременно — как бы самоочевидно. Зато каждая из них была достаточно проста и было понятно что в них происходит. Сейчас же та же логика размазана по двум десяткам функций и для того, чтобы всё это не разъехалось пришлось написать не один десяток тестов. Где, понятно, тоже могут быть ошибки. Притом что за четыре года ни одной ошибки, которая могла бы проявиться на практике, в исходном коде не было найдено, а в «улучшенном» кода такие ошибки были — не могу сказать, что я прям в восторге от проделанной работы.
Притом из чисто теоретических соображений я понимаю, почему маленькие функции лучше и почему тестирование — это замечательно и т.д. и т.п. Вот только практически я этого эффекта не наблюдаю.
Притом из чисто теоретических соображений я понимаю, почему маленькие функции лучше и почему тестирование — это замечательно и т.д. и т.п. Вот только практически я этого эффекта не наблюдаю.
Все подобные красивые и правильные рассуждения страдают от недостатка метрик и формальных определений. И это помимо всяких метрик сложности по памяти, по времени исполнения и т.д.
Куча разных критериев, удобство сопровождения, понятность для коллег по code review. Что такое читаемость, что такое наглядность, что такое выразительность? Какие-то субъективные критерии, которые легли на девственно чистый участок коры головного мозга авторитетного автора, пока он работал на первой быдлокодерской работе. Как всегда недостаточно весомые критерии для публичных рассуждений.
Кто-то пытается выехать на актуальных трендах, типа, stream вместо foreach, как раньше выезжали на foreach вместо while. Кто-то считает строки. Кто-то ветвления считает. Кто-то просто выдумывает красивые и звонкие мемы и аллегории, как на картинке.
В итоге все превращается в выяснение истины методом голосования.
Куча разных критериев, удобство сопровождения, понятность для коллег по code review. Что такое читаемость, что такое наглядность, что такое выразительность? Какие-то субъективные критерии, которые легли на девственно чистый участок коры головного мозга авторитетного автора, пока он работал на первой быдлокодерской работе. Как всегда недостаточно весомые критерии для публичных рассуждений.
Кто-то пытается выехать на актуальных трендах, типа, stream вместо foreach, как раньше выезжали на foreach вместо while. Кто-то считает строки. Кто-то ветвления считает. Кто-то просто выдумывает красивые и звонкие мемы и аллегории, как на картинке.
В итоге все превращается в выяснение истины методом голосования.
К сожалению, даже метрики и формальные определения не всегда помогают. Вот, например, один из самых больных для обсуждения требование к стилю — длина строк не должна превышать 80 символов. Несмотря на то, что есть логические предпочтения для этого, абсолютное большинство голосуют против этого: «мы же не в каменном веке терминалов!!!» А то, что:
их не волнует. К сожалению, многие разработчики имеют практически религиозную фанатичность насчет некоторых практик и инструментов, и только голосование (или в худшем случае, когда даже это не работает, официальное требование от руководства) может повлиять на изменение стиля.
P.S. Хотел бы отметить один момент с layout-ами — многие возражают, что сейчас у всех много (2+) мониторов на работе. Тем не менее, современная практика разработки программного обеспечения (не уверен насчет России) включает в себя WFH (Work From Home), и дома у большинства нет лишних мониторов. WFH становится более и более популярным потому что это снижает риск эпидемий на работе (болеешь, можешь сидеть дома и работать, тем самым не теряя зарплату) и современные технологии практически исключили требования иметь всех под боком в любой момент времени.
- вообще-то с терминалами до сих приходиться работать (SSH в AWS/другие облака),
- code review для длинных строк кода очень тяжело делать (потому что в основном это side-by-side comparison),
- некоторые разработчики предпочитают другие layout-ы на экранах — например, иметь консоль с логами от watcher-а (gradle watch, grunt etc) или в целом просто tail -f логами рядом с редактором кода
их не волнует. К сожалению, многие разработчики имеют практически религиозную фанатичность насчет некоторых практик и инструментов, и только голосование (или в худшем случае, когда даже это не работает, официальное требование от руководства) может повлиять на изменение стиля.
P.S. Хотел бы отметить один момент с layout-ами — многие возражают, что сейчас у всех много (2+) мониторов на работе. Тем не менее, современная практика разработки программного обеспечения (не уверен насчет России) включает в себя WFH (Work From Home), и дома у большинства нет лишних мониторов. WFH становится более и более популярным потому что это снижает риск эпидемий на работе (болеешь, можешь сидеть дома и работать, тем самым не теряя зарплату) и современные технологии практически исключили требования иметь всех под боком в любой момент времени.
Про 80 символов — сильно зависит от языка. В той же Java бывают имена классов по 30 символов. Если ограничивать по 80 в таких условиях (учитывая ещё отступы по 4 пробела), код начинает выглядеть откровенно уродливо. На перле 80 символов — вполне адекватно.
Естественно, не зря современный стандарт — 80/120 (и ситуация намного хуже для конфигураций, где, например, в том-же JSON-е из-за отсутствия многострочных литералов приходится иногда писать очень длинные строки). Я больше ссылался на разработчиков, которые имея возможность писать короткие строки, тем не менее пишут код длиной до 2800 символов в строке (реальный пример, я сам не мог долго поверить своим глазам и все попытки убедить, что так делать не надо, уперлись в каменную стену фанатичности: «я — snowflake, что хочу то ворочу, и никто мне не указ»).
КстатиИменаСущностейПоСтопицотСимволов — это тоже плохой стиль, я считаю.
Касательно читаемости, на мой взгляд, есть очень простая метрика — любой код в команде должен выглядеть как написанный тобой. Это идеал, к которому надо стремиться
То есть если Вася умеет реализовывать сложные математические алгоритмы, но не умеет обрабатывать сложные структуры данных, а Петя успешно обрабатывает сложные форматы данных, но у него плохо с математикой, то в коде не должно быть ни сложных структур данных, ни сложной математики? Ну и куда вы зайдёте с таким «идеалом»?
А в попугаях это сколько?
Так вот всё время твердит, что java тормозит.
Пусть Джон и признается, что отчасти не сторонится в жизни строгих комментариев, ему далеко до Линуса Торвальдса
Едва ли мы об этом узнаем. Разработка ядра Linux ведётся в списке рассылки, в котором каждый может принять участие в качестве читателя или писателя. Это одновременно и преимущество (открытость), и недостаток — появляются подобные суждения. Линус тоже говорил, что хороший пинок бывает полезен для человека, просто так он никого не ругал.
А меня задела в статье суперполиткорректная картинка, где девушка суперпрограммист учит жизни говнопрограммиста парня. Не видел таких случаев.
С нетерпением жду новых исторических сериалов, например, про Эйнштейна и его теорию, где он будет черной девушкой-феминисткой. А то неудобно как-то — великий ученый — и опять мужик? Дискриминация, понимаешь.
С нетерпением жду новых исторических сериалов, например, про Эйнштейна и его теорию, где он будет черной девушкой-феминисткой. А то неудобно как-то — великий ученый — и опять мужик? Дискриминация, понимаешь.
Забавно, что ни один из минусующих не возразил: «нет, вот конкретно у нас была такая крутая девушка-программист». То есть, минусуют за сам факт, потому он неприятен? Ну заминусуйте еще за факт, что 99% научных открытий (проверить легко по статистике Нобелевских лауреатов) совершается мужчинами и что 99% детей рожается женщинами. Ну про 99%, это я политкорректно написал. В-)
Мой первый — и длительный — серьезный опыт в программировании выглядел похожим образом, разве что ждать приходилось не сорок минут. У меня была программа на С++, написанная в С стиле, с использованием void указателей вместо темлейтов (что я аргументировал, фактом наличия таких указателей в функциях стандартной библиотеки С, а темплейты слишком ужасно выглядят).
Чтобы найти только одну ошибку, которую я бы мог обнаружить, если бы умел правильно писать код, мне приходилось готовый бинарник переложить в определенную директорию, переключиться на терминал, подключенный к устройству, откуда командой «tftp -gr file $IP» скачать файл, затем не забыть дать ему исполняемые права, затем переместить в другую директорию на замену старого приложения, затем убить старое приложение, затем подождать некоторое время, пока его перезапустит демон, затем на ПК в клиентской части приложения сделать еще несколько пассов, и получить сегфолт. Затем проделать часть манипуляций, связанных с запуском gdbserver, и подключением к нему, снова воспроизвести сегфолт, и, наконец, заняться изучением причин.
Но чаще всего сегфолта не возникало, а просто что-то работало неправильно, и все нудные манипуляции приходилось повторять полдня, чтобы только найти одну проблему.
Постепенно я понял, что надо писать код так, чтобы по максимуму ошибок можно было обнаружить на этапе компиляции. Не последнюю очередь в этом сыграло и изучение языка Haskell — который, кстати, весьма рекомендую людям не знакомым с ним: даже, если вам не придется работать с этим языком за деньги, он научит вас писать код действительно правильно, даже на других языках.
Чтобы найти только одну ошибку, которую я бы мог обнаружить, если бы умел правильно писать код, мне приходилось готовый бинарник переложить в определенную директорию, переключиться на терминал, подключенный к устройству, откуда командой «tftp -gr file $IP» скачать файл, затем не забыть дать ему исполняемые права, затем переместить в другую директорию на замену старого приложения, затем убить старое приложение, затем подождать некоторое время, пока его перезапустит демон, затем на ПК в клиентской части приложения сделать еще несколько пассов, и получить сегфолт. Затем проделать часть манипуляций, связанных с запуском gdbserver, и подключением к нему, снова воспроизвести сегфолт, и, наконец, заняться изучением причин.
Но чаще всего сегфолта не возникало, а просто что-то работало неправильно, и все нудные манипуляции приходилось повторять полдня, чтобы только найти одну проблему.
Постепенно я понял, что надо писать код так, чтобы по максимуму ошибок можно было обнаружить на этапе компиляции. Не последнюю очередь в этом сыграло и изучение языка Haskell — который, кстати, весьма рекомендую людям не знакомым с ним: даже, если вам не придется работать с этим языком за деньги, он научит вас писать код действительно правильно, даже на других языках.
В науке это нормальное дело. У меня была программа на python, которая запускала программу на C++, которая читала вывод из Maple и потом передавала данные назад, а программа на python строила график. Даже если бы я к статье приложил этот код, не думаю чтобы он кому-то помог :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миллион строк плохого кода