Комментарии 61
Расскажите мне что делает это код?
Признаюсь, подумал что первый код понятнее чем второй, пока не прочитал правильный ответ. Такие дела.
Первый код действительно проще: два вложенных прогона массива и все. А второй — какие-то методы, которые где-то в другом месте применяются. Эти два куска кода просто некорректно сравнивать.
Но вот если мы возьмем первый код и попытамся понять, чем же там оперируют, тут вот, возникнут вопросы:
Что такое $u, почему не назвать $userData, может быть это что-то другое? и почему вдруг запрашиваем по 'u', неужели там так таблица названа?
Где-то в середине у нас есть $value и $value2 — это вообще как понимать? лезть в бд?
Потом череда магических чисел и какой-то ключ vis. Плохо спроектирована БД? исправь это функцией-геттером.
Ну и в целом, возвращаем мы true, false, а что становится ими — не известно.
Так неважно же "почему не назвать". Такая мысль мне даже в голову не пришла. Там в функции описана тривиальная логика, где нейминг не играет решающего значения — всё понятно и без него. Хотя да, с ним было бы лучше.
И в целом неважно что за vis — для начала надо понять общую логику и только потом разбираться откуда что берётся если понадобится.
vis — по-голландски рыба. Определенно выставляют флаг, любит ли рыбу пользователь!
Второй foreach на каждой итерации перезаписывает переменную $value['vis'], можно с таким же успехом просто взять только последнее значение $value['p'], прогнать через if и записать $value['vis'] один раз.
$f и $key вообще не используются.
Автор вроде бы нигде и не говорит что есть какой-то один идеальный стиль. Как раз таки наоборот он говорит что стиль можно выбирать какой угодно. Главное чтобы все потом его придерживались.
Что значит "его нет"? У вас вообще нет никаких правил? Даже неписанных? Даже чего-то вроде "локальные переменные пишем с маленькой буквы"? Или "не испоьзуем русский язык в названиях"? Наверняка же есть.
В том и смысл статьи что надо определить какой-то для вашей фирмы оптимальный набор правил и сделать так чтобы его все придерживались. И чем больше таких правил и чем они точнее прописаны, тем более читаемым будет ваш код для среднего сотрудника.
google.github.io/styleguide/javaguide.html. Он не такой жесткий, весьма краткий и вполне выполним для большинства разработчиков. Я придерживаюсь похожего подхода.
Автор же в примерах кода показывает, что он сторонник одного подхода и считает, что все должны ему следовать:
В этом примере мы просто берем весь репозиторий, потом используем builder, чтобы создать коллекцию, потом применяем фильтр.
Я считаю, что упорно настаивать на каком-то конкретном подходе принесет только вред и разочарование обоим сторонам. Зачем тогда было нанимать этого разработчика, ты же видел его код? Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.
Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.
А кто у вас решает удовлетворяет код этим параметрам или нет? Каждый для своего кода? Есть какие-то код-ревью и кто их тогда проводит? Есть кто-то вроде тимлида, который контролирует весь код?
Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате.
Тимлид, естественно, должен быть ответственнен за весь код, выпускаемый его командой, но апрувить может любой опытный член команды.
Тогда получается что если скажем для джунов/мидлов код сложно читается, то это никто и не заметит.
И самое главное вопрос в том насколько понятен будет этот код через два-три-четыре года когда будут новые "опытные" со своим новым стилем написания кода.
Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате
Никто не говорит что нельзя работать или вводить новых людей в курс дела и без всякого code style. Можно. Но имея адекватный code style это становится проще. И если всё сделать более-менее адекватно, то "затраты" на привыкание всех сотрудников к общему стилю "окупаются" относительно быстро.
И можно кстати это делать поэтапно и не вводить все правил сразу за один приём. Тогда и сопротивляется народ меньше и привыкает проще.
Но имея адекватный code style это становится проще.
Ни один вменяемый разработчик не будет оспаривать нужность code style в каком-то виде. Более того, это сто раз описано во всех best practices.
И самое главное вопрос в том насколько понятен будет этот код через два-три-четыре года когда будут новые «опытные» со своим новым стилем написания кода.
А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50.
Тогда и сопротивляется народ меньше и привыкает проще.
Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».
А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50
Проблема в том что "несложно" это всё-таки очень субъективное понятие. Например если ты хорошо знаешь все бизнес процессы и свой код, то тебе не особо и надо писать комментарии или просто называть переменные/методы "говорящими" именами.
А вот через 5-10 лет разбирать такой легаси код новому человеку будет уже сложно.
Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».
"Излишне" это тоже достаточно субъективная вещь. И естественно палку перегибать не стоит. Но при этом я лично несколько раз был и по ту и по другую сторону баррикад когда поначалу сопротивлялись вполне себе полезным изменениям. И потом уже и сами признавали что они были полезными.
Проблема в том что «несложно» это всё-таки очень субъективное понятие.
Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать. А если при этом еще материться не будет — значит Вы сделали все как надо :).
Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать.
Вы извините, но то что вы перечислили это цель, а не "рецепт". С тем что надо писать именно такой код никто и не спорит. Вопрос в том как это делать.
И если у вас на фирме это получается само собой и без особых усилий/процессов, то я вам очень завидую. На фирмах где работал я обычно приходилось прикладывать усилия чтобы это более-менее получалось.
Если говорить по теме, то просматривая сотни кода иногда удивляюсь тому что было в душе у того кто пишет код размазывая его по экрану как бог пошлет, рандомные отступы, рандомные переносы.
21-й век а люди продолжают писать плохо читаемый код.
Рандомными они могут лишь казаться, а по факту может оказаться, что когда-то была система, а при внесении изменений в код на неё забили, а может просто не знали или внедряли свою
Деморализует ужасно — реально доходит до того, что я когда сажусь разбираться в таком куске кода — сразу накатывает уныние и желание пойти сменить место работы.
Вот как просто объяснить джуньорам что code style важен? По моему опыту процентов 90 его игнорируют, начинаешь вводить драконовские меры — начинают хныкать и обижаться. Что делать?
Простые решения — это всегда хорошо, при условии, что они работают и оправдывают себя.
все молодые кого знаю, пытаются вскочить в IT поезд, правдами и неправдами.
Потому что молодые знают, что дальше будет интереснее — роботы, AI, всеобщее подключение к сети. IT открывает огромные возможности, в Америке даже джуны на расхват, я уж не говорю о сеньорах, за которых бьются лучшие компании. Да даже в Москве выпускник вуза, умеющий программировать, может смело претендовать на соточку в месяц. В 90-е такого спроса не было…
Во всяком случае не в вебе.
Даже мидл с резюме средней паршивости может искать работу по пол года.
Да, если хорошо поработать над резюме и «интервью проходительными скилами», или если готов переехать в «заповедники программистов» то без работы не останешься, но, например, в Пенсильвании человек с 3мя годами опыта в JS+React+немного PHP+SQL (1 лет 10 в IT вообще) искал работу, емнип, год.
А вот на стройку его в тот же день взяли, при чём после звонка по первому обьявлению из бесплатной газеты. Вот это я понимаю «на расхват» :)
При чём когда он таки нашёл работу вэб разработчиком и уходил со стройки, ему предлагали те же деньги что-бы остался. Но там просто человек с руками и головой дружит.
Году в 2000-м квартиру в Питере можно было купить тысяч за 5 долларов. Где-то в других регионах, и того дешевле. При рейте долларов 20 в час вполне на квартиру хватило бы, не самую плохую на, например, Камчатке — сам продавал в то время.
Драконовские меры — да. Чекинг стилистики и принципов один из пунктов ревью. Не должно быть конфликтов, должны быть написаны тесты, не должен упасть регресс, линтер должен быть зеленым. Культура прививается только контролем. Дети иногда бегают через дорогу, джуны иногда пишут код не по правилам. Задача наставника — научить и воспитать :)
Самый простой вариант это дать им переписывать на чистую или рефэкторить какой-нибудь легаси проект у которого вообще никогда не было никакого code style.
П.С. Это конечно если что-то подобное имеется в наличии.
У нас кодстайл внедряться начал мной после прихода на новое рабочее место. В плане кодстайла я немного параноик, поэтому был введен длинный список правил сначала на CodeSniffer, конфиге к шторму и MD файле со списком типовых архитектурных решений. По началу в шторме весь файл светился варнингами, а на ревью было по десятку замечаний. Некоторых это утомляло. Некоторые выступали против. Но, благо, начальство было на моей стороне, поэтому эта практика внедрялась все глубже и шире. В конечном итоге все привыкли писать сразу правильно. Потом подключили php-cs-fixer с пачкой правил, в том числе и самописных, и мы просто разом прогнали его по всему проекту, сделав код почти единообразным. В итоге скорость чтения и написания кода увеличилась у всей команды, а код-ревью стало гораздо более простым делом.
Талант можно проявлять в элегантных решениях, чем в общем-то и блещет наш тим-лид, создавая по-настоящему изящный код. А код-стал, как по мне, не то место, где можно выпендриваться.
А потом было решено перейти на google code style.
Учитывая, что часть народа игнорирует рекомендации по стилю, а железной руки нет, получается ужасная каша из старого стиля, нового стиля и безстилья.
Тихий ужас и кошмар.
Не очень понятно зачем вам был нужен такой сложный и длинный путь, у нас в компании все намного проще. Не рискованные изменения по кодстайлу применяються автоматически при коммите, рискованные запусаются, но не применяються, а только выводятся на экран. На CI сервера происходит тоже самое, и пока код стайл не будет исправлен, данный мердж реквест не может быть смерджен.
По мимо этого еще есть phpstan который проверяет правильность самого кода, phpmd, phpcpd и многое другое.
Вспомним 2 главные проблемы программирования? Инвалидация кеша и нейминг переменных.
А как же «off-by-1 errors»?
Пока разработчик разбирается в чужом (или даже своём старом) коде, пытаясь понять, что он делает, он не занимается непосредственно работой.
Не согласен. Это непосредственная работа, в большинстве случаев обязательная. Вопрос лишь в том, какой КПД у этой работы, сколько времени потребуется, чтобы разобраться в одной и той же по сути логики — в зависсимости от архитектуры, именования, кодстайла и т. п. время может различаться даже не в разы, а на порядки.
По сути можно говорить о количестве привнесённой технической сложности к натуральной сложности бизнес-логики. Когда станет возможно привести его к нулю, программисты будут не нужны, понятие программы в классическом виде исчезнет.
И лишние Ь-знаки намекают нам, что автор ещё и двоечник по русскому.
Code style как стандарт разработки