Comments 50
Если бы всё было гладко так, как Вы говорите, как минимум этой статьи бы не было.
Вдобавок, инструменты помогают поддерживать правильный стиль, но сам факт необходимости его использования должен быть в голове разработчика.
К сожалению, очень часто сталкиваюсь с отношением к стилю кода как к "херне, которую спрашивают только на собесе".
Но если разработчики готовы улучшать свои показатели, то начальникам это не всегда нравится. Для примера, на одной из прошлых моих работ был обязательный код-ревью. Новички в отделе его проходили долго, контроллировал их. Какое-то время начальник отдела терпел время, потраченное на это дело, после чего психанул и сказал "чтобы не смели тратить время в пустую — выгружай как есть, у нас задач вагон". И всё пошло по известному месту.
Вдобавок, инструменты помогают поддерживать правильный стиль, но сам факт необходимости его использования должен быть в голове разработчика.
Для этого достаточно настроить препуш хуки и для надежности навесить автоматическую проверку на стороне ci/cd.
Команды разные и требования к коду разные, а еще зачастую могут разниться от языка к языку — js/php и как Вы и заметили заставлять проверять это вручную — путь в никуда )
Что мешает изначально писать красиво, не полагаясь на инструменты?
Мешает догадка, что дальше это будет читать психопат, знающий, где ты живёшь.
Если вы уже взрослый, и знаете, что жизни конечна, вам психопат до лампы (ну максимум больно убьёт, ну колекой сделает... но это не очевидно). Это вам позволяет сосредоточенно делать красивый код, очень медленно.
Других вариантов делать красивый код не бывает.
Никакие линтеры не изменят архитектуру, где всё свалено в одну кучу. А в ней как раз и заключена причина дальнейших сложностей.
Вот я Вас не понимаю. В начале Вы пишете против меня, что разрабам должно быть чхать на всех и вся в попытках оправдать скоротечность жизни, а в конце Вы же пишете что именно это и плохо, то есть соглашаетесь с моим мнением изначально писать красиво, как любят говорить некоторые, "для себя".
Нене. Сначала я возражаю против пословицы. Вы её процитировали, но вы же сами не очень-то с ней согласны.
Разве что речь о себе самом. Это вот да. Тот негодяй, что смотрит на вас из зеркала (ну или негодяйка), это, бывает, очень тяжёлая личность. И знает, где ты живёшь. Где ешь. Где спишь. Может ни на секунду не отпускать. Поди попробуй что-нибудь напиши не так.
Мне, например нравится после объявления класса/структуры переносить открывающую скобку на новую строку. Но совершенно не нравится переносить на новую строку открывающую скобку в функциях в теле класса. Особенно в функциях — однострочниках.
Но это мои предпочтения.
По сути, вообще нет разницы где и как писать код. Вот что нужно, так это писать его читаемым, а не как многие делают.
Предметно к сожалению спорить не готов, так как я совсем не пхпшник, но что-то мне подсказывает что советы в духе «отступы следует делать по 4 пробела» и «открывающиеся скобки лучше переносить на новую строку» это чистой воды бессмысленный микроконтроль и в вашей экосистеме.
А ещё IDE умеют в автоформат кода.
Но совершенно не нравится переносить на новую строку открывающую скобку в функциях в теле класса. Особенно в функциях — однострочниках.
Поэтому в C# можно в таких случаях вообще без скобок обойтись, с использованием =>.
Почему 2 пробела плохо читается код а 4 хорошо?
Ну ладно, 2 пробела или 4 – вкусовщина. Хотя у вас безапелляционное утверждения про 4 пробела.
Но обязалово пробелов вместо табов? Аргумент вообще не от мира сего. Приведенные примеры не состоятельны от слова совсем. Вернее приведенные пример как бы и показывают всю прелесть использования табов, по крайней мере в начале строки. Так как из примеров видно что у отдельно взятого разработчика код будет показан в удобном для него виде.
Если что мне как раз удобнее пробелы, но у меня это именно два пробела.
Почему таб лучше пробела — написано текстом в статье и предоставлены примеры.
По поводу количества, два пробела смазываются в глазах при чтении. С четырьмя глаз лучше видит вложенность элементов. Конечно, если не смотреть в монитор с расстояния в 15 сантиметров.
Мне нравиться 2 пробела. Монитор 32”, 4К, 100% маштаб, до монитора примерно метр. 2 пробела, для меня, более чем достаточно. И в своих пет-проджект я использую те настройки, которые удобны и симпатичны мне.
Сильно зависит от зрения. В моем случае все ок. Хотя за компом лет с 15.
Сначала это был клон spectrum и был не монитор, а телевизор. Только года с 2000 появился нормальный PC с монитором. И только с 2007 перешел на мониторы с нормальной матрицей.
Видимо просто от природы повезло.
Но мои коменты выше как раз про то, что неправильно всех под одну гребенку.
PS.: очень кстати бесит тенденция делать гигантский шрифт на большом разрешении на сайтах.
Символы табуляции лучше не использовать
Ну да, как же...
"НравиТСЯ". И показываться будет не так как нравится автору, а как будет принято в команде.
Дон Кихот прям какой-то…
вы работали когда то с большими и старыми системами? или системами где используются активно компоненты с открытым исходным кодом? в таких ситуациях везде будет разный стиль, где то нравится где то нет, и чем боротся с ветряными мельницами навязывая свои вкусы пора бы уже повзрослеть и научится читать код с разным кол-ом пробелов. так сказать расслабился и начать работать.
Также отступы следует делать в 4 пробела, так как такой код лучше воспринимается человеческим глазом.Весьма смелое обобщение.
Символы табуляции лучше не использовать, т.к. на каждом устройстве в каждом окружении может по-разному быть настроен размер табуляцииА вы не задумывались, почему он настраивается?
Возможно, «человеческий глаз» у всех разный?
Хоспаде, дочитайте уже до конца.
Дочитал до конца, дальше вот что:
Размер в два символа лучше не использовать по той причине, что код становится нечитабельным и выглядит как "по линейке" — в одну слегка кривую вертикальную линию. И отследить в таком массиве вложенные операторы становится проблемной задачей.
В чем проблема, что другой будет видеть код таким, каким он привык? Вы считаете, что с 2 пробелами у всех проблема отследить вложенность?
Если у вас проблемы с 2 пробелами, то при использовании табов у вас-то код будет выглядеть так, как вам привычно.
Есть ведь тимлиды, которые считают, что 2 пробела — мало, 4 — много, а 3 — в самый раз. И они с такой же как у вас логикой заставляют всех полюбить 3 пробела.
До конца, это до раздела "заключение" с этим текстом:
P.S.: Уже несколько людей, включая сообщения вне Хабра, написали о том, что есть такие штуки как PSR, автокомплит кода, форматирование кода в IDE, cs-fixer и так далее. Вы правда думаете, что я не знаю о их существовании? Проблема, раскрытая в статье, не в том, что их не используют, а в том, что мешает изначально красиво писать код, не поджигая пуканы других разработчиков?..
В своём посыле я пытаюсь объяснить, что нужно не полагаться на средства разработки, а изначально стараться писать код чисто и не важно сколько в нём пробелов и табуляций. Пример был показан только как пример, но именно на него, почему-то, сагрились почти все комментаторы и здесь, и в чатах. Несмотря на то, что это тупой, блин, пример показывающий всего лишь разницу восприятия, не более.
И что больше всего мне не нравится — 99% комментаторов вообще не поняли смысл написанного, зацепившись, опять таки, за примеры.
2. Читаемый код не существует в вакууме. Открываешь несколько топовых проектов на конкретном языке в гитхаб, смотришь кодстайл и используешь. Всё. Точка. За тебя придумали — используй. Нонконформизм, типа, мы знаем, как более правильно — не работает. Нужна программа, нужна автоматизация бизнеса, а не сам код в каком-то стиле.
Блок "заключение":
P.S.: Уже несколько людей, включая сообщения вне Хабра, написали о том, что есть такие штуки как PSR, автокомплит кода, форматирование кода в IDE, cs-fixer и так далее. Вы правда думаете, что я не знаю о их существовании? Проблема, раскрытая в статье, не в том, что их не используют, а в том, что мешает изначально красиво писать код, не поджигая пуканы других разработчиков?..
ESLint тоже та ещё муть. Поднимал несколько фронтовых проектов и из коробки он работает отлично, НО вообще не вписывался в кодстайл, установленный нашей командой.
В итоге потратил пару дней на исправление его правил, чтобы работало так, как надо. Первая проблема — заменить 2 символа на 4 в табуляции. И всё. С половину правил нужно переопределять, куря маны.
Вот это действительно зачёсывание разработчиков под одну гребёнку...
В начальной статье я примеры в качестве примеров добавил, а народ посчитал их основной сутью статьи и начал придираться то к скобкам, то к пробелам. Убрал, чтобы не отвлекались более.
Как вам верно написали IDE сама отформатирует. И есть PSR.
Основные претензии читающих были в том, что советы ваши не как советы оформлены, а как истина в последней инстанции. И не программисты те, кто не делает так же.
Вышла на ваш аккаунт из гугла, в поисках чего-нибудь там насчёт безопасности вычитывания модели в параметрах контроллера в ларавель, типа
public function show(Article $article) в контроллере,
в роутере, соответственно, Route::get('/{article}, 'ArticlesController@show').
Это же никакой валидации от программиста - вся надежда, что где-то там в недрах фреймворка сразу отсеивается всё, что не подходит под айди статьи (если бы были проверки, было бы что-то вроде "это - натуральное число в каких-то пределах".
Попала, конечно, на вашу статью о распространённых ошибках безопасности.
Но яко же я адский прокрастинатор, я пошла всё читать.
Вот сижу вою просто от этой статьи. Штош вы примеры стёрли???... Аааа...
И да, я бы конечно поставила бы плюсик к статье, но почему-то нет стрелочек. На хабре нельзя оценивать статью год спустя? И комментарии нельзя тоже оценивать год спустя? Неочевидная ситуация (стратегически, я имею в виду. То, что так может быть сделано чисто технически, я понимаю).
ЗЫ контроллеры на 3000 строчек, вообще без внешних деталей
(всё проверяем на месте;
$request->only(...) не юзаем - расписываем подробно все-все поля в create/update,
... )
вот она, правда жизни. И как это вставишь в статью?
Добрый день.
Да, старые статьи оценивать нельзя, такая фича.
Все примеры, которые я писал в посте, на месте.
Что касается автобиндинга, Laravel использует фильтрацию запросов от SQL инъекций, вдобавок, при биндинге используется каст поля идентификатора, определённого в модели. По-умолчанию, это integer. В случае если что-то неподходящее попытаются пропихнуть, бэк вернёт ошибку 404. Если же Вы хотите вручную дополнительно валидировать данный параметр, никто не запрещает это делать - метод `where` с регуляркой на роутах тому подтверждение. Подробнее в доке.
Контроллеры на 3к строк? Жуть какая.
Году в 2004-2005 начал пользоваться первой своей IDE для разработки - NetBeans. PhpStorm в то время только-только появился и нервно курил в сторонке по сравнению с "инет-бобами". Так вот, одной из рекомендаций NetBeans по длине было стараться держать метод длиной не более 21 строки и длину класса не более 200 строк.
$request->only(...) не юзаем - расписываем подробно все-все поля в create/update,
То есть что-то вроде:
$page = new Page();
$page->title = $request->get('title');
$page->content = $request->get('content');
// ...
$page->save();Именно для решения данной проблемы и существует массовое заполнение.
Например, есть два роута: создание и изменение записи.
Кейс: при создании заполнять поля "title", "content" и "author", а при обновлении только "content".
Реализация: на фронте для обоих случаев используем одну форму, но с разными вызываемыми маршрутами. Не спрашивайте почему, пусть так исторически сложилось :)
Используя массовое заполнение мы с лёгкостью сможем реализовать данный кейс следующим методом:
class CreateRequest extends FormRequest
{
public function rules()
{
return [
'title' => ['required', 'string', 'max:255', 'unique:posts,title'],
'content' => ['required', 'string', 'max:3000'],
'author' => ['required', 'integer', 'exists:users,id']
];
}
}
class UpdateRequest extends FormRequest
{
public function rules()
{
return [
'content' => ['required', 'string', 'max:3000'],
];
}
}
class PostController extends BaseController
{
public function store(CreateRequest $request)
{
return Post::create($request->validated());
}
public function update(UpdateRequest $request, Post $post)
{
$post->update($request->validated());
return $post;
}
}И всё, метод validated вернёт только то, что было валидировано в форм-реквесте, исключая всё иное.
А по поводу вставки в статью не понял что именно.
Спасибо за подробный ответ,
а проверяет ли биндинг длину этого integer? Вроде бы, если вставлять чтонибудьоченьдлинное(намиллионсимволов), это пройдёт по сети, но где-то там в недрах сервера будут проблемы? Вообще говоря, это моя вольная интерпретация слышанного где-то краем уха: если мы передаём очень длинные числа, там начинаются переполнения памяти и тому подобное. Но деталей не знаю.
Про вставку в статью я имела в виду код на 3000 строк:) Даже под катом может не поместиться.
И кстати да, я не знала, что при валидации собственными реквестами ->validated() вернёт только выверенные поля. Я думала, он вернёт все поля, просто некоторые (про которые мы подумали и указали реквесте) пройдут валидацию, поэтому всё равно надо ->only(...) указывать. Очень большое спасибо за уточнение.
АПД а почему вы используете $request->get('title') например, а не $request->title?.. В принципе да, так вроде бы красивше. Но я ни разу не видела такого использования, кажется (ушла читать доку по теме).
Биндинг не проверяет, это делает сам MySQL в зависимости от типа поля. По-умолчанию, Laravel использует в качестве типа поля для автоинкремента тип "unsigned big integer", что соответствует размеру от 0 до (2^64)-1 степени.
Кроме того, программиста вообще не должна волновать такая проблема. Его задача произвести проверку заполняемых данных, в идеале, в двух слоях валидатора: первый при получении запроса от пользователя и второй перед записью в базу, так как между ними данные могут быть преобразованы.
Дальше, вставлять в пример контроллер на 3к строк плохая идея как минимум потому, что против такого кода я и писал статью)
По поводу форм-реквестов в Ларе можете почитать офф доку:
https://laravel.com/docs/9.x/validation#working-with-validated-input
https://laravel.com/docs/9.x/validation#form-request-validation
По поводу $request->get('title') - это явные запросы против магических $reqeust->title. Да, IDE их подсказывает (если её научить хелперами, например, генерируемыми при помощи Laravel Idea, но как по мне, то это костыль, что ли. Вдобавок, часто сталкиваюсь с требованиями, когда нужно вернуть дефолтное значение если оригинальное не обнаружено.
Просто сравните два участка:
$title = $request->title ?? 'default';
$content = $request->content ?? 'coming soon';
// or
$title = $request->get('title', 'default');
$content = $request->get('content', 'coming soon');Как по мне, то второй вариант приятнее глазу.
Заметки о codestyle