Открыть список
Как стать автором
Обновить

Комментарии 42

Учится стилю надо начинать с PSR-2 и PSR-12 (в случае php), а лучше с инструментов которые будут держать код проекта в тонусе )) а не заставлять команду ревьюить codestyle :)

Если бы всё было гладко так, как Вы говорите, как минимум этой статьи бы не было.


Вдобавок, инструменты помогают поддерживать правильный стиль, но сам факт необходимости его использования должен быть в голове разработчика.


К сожалению, очень часто сталкиваюсь с отношением к стилю кода как к "херне, которую спрашивают только на собесе".


Но если разработчики готовы улучшать свои показатели, то начальникам это не всегда нравится. Для примера, на одной из прошлых моих работ был обязательный код-ревью. Новички в отделе его проходили долго, контроллировал их. Какое-то время начальник отдела терпел время, потраченное на это дело, после чего психанул и сказал "чтобы не смели тратить время в пустую — выгружай как есть, у нас задач вагон". И всё пошло по известному месту.

Вдобавок, инструменты помогают поддерживать правильный стиль, но сам факт необходимости его использования должен быть в голове разработчика.

Для этого достаточно настроить препуш хуки и для надежности навесить автоматическую проверку на стороне ci/cd.

Команды разные и требования к коду разные, а еще зачастую могут разниться от языка к языку — js/php и как Вы и заметили заставлять проверять это вручную — путь в никуда )

Что мешает изначально писать красиво, не полагаясь на инструменты?

Пример 1 со скобками — это типичный источник холивара.
Мне, например нравится после объявления класса/структуры переносить открывающую скобку на новую строку. Но совершенно не нравится переносить на новую строку открывающую скобку в функциях в теле класса. Особенно в функциях — однострочниках.
Но это мои предпочтения.
Меня скобки вообще не напрягают. В 2021 все нормальные IDE могут в разметку вложенности и фолдинг, так что без разницы. Считаю это ребячеством, холиварить из-за скобки на той же или новой строке.

По сути, вообще нет разницы где и как писать код. Вот что нужно, так это писать его читаемым, а не как многие делают.

Скобки эти не влияют на читаемость. На читаемость влияет чистый код и нормальная документация для хотя бы открытого апи.
Есть мнение что понятие читаемости — штука очень субъективная, и то что на одном проекте будет считаться образцом стиля, на другом будет вызывать массовое вытекание глаз.
Предметно к сожалению спорить не готов, так как я совсем не пхпшник, но что-то мне подсказывает что советы в духе «отступы следует делать по 4 пробела» и «открывающиеся скобки лучше переносить на новую строку» это чистой воды бессмысленный микроконтроль и в вашей экосистеме.
Не говоря уже о разных стандартах языков. Лично я не вижу проблемы в 2 или 4 пробелах.

А ещё IDE умеют в автоформат кода.

А ещё говорят, что статьи нужно до конца читать...

Но совершенно не нравится переносить на новую строку открывающую скобку в функциях в теле класса. Особенно в функциях — однострочниках.

Поэтому в C# можно в таких случаях вообще без скобок обойтись, с использованием =>.

В php 8 тоже. Завезли стрелочные функции.

Да, тупанул. В восьмёрке именованные аргументы завезли и объявление свойств в конструкторе.

Не понятно почему таб вместо пробела плохо. Если что сам пользую пробелы.
Почему 2 пробела плохо читается код а 4 хорошо?
Ну ладно, 2 пробела или 4 – вкусовщина. Хотя у вас безапелляционное утверждения про 4 пробела.
Но обязалово пробелов вместо табов? Аргумент вообще не от мира сего. Приведенные примеры не состоятельны от слова совсем. Вернее приведенные пример как бы и показывают всю прелесть использования табов, по крайней мере в начале строки. Так как из примеров видно что у отдельно взятого разработчика код будет показан в удобном для него виде.
Если что мне как раз удобнее пробелы, но у меня это именно два пробела.

Почему таб лучше пробела — написано текстом в статье и предоставлены примеры.
По поводу количества, два пробела смазываются в глазах при чтении. С четырьмя глаз лучше видит вложенность элементов. Конечно, если не смотреть в монитор с расстояния в 15 сантиметров.

Полотно писать не нужно и все. В многих языках по 2 пробела и норм.
Как раз в статье говорят, что не надо использовать таб. Типа без табов у всех будет показываться так как нравиться автору, а на ваши предпочтения автору глубоко …
Мне нравиться 2 пробела. Монитор 32”, 4К, 100% маштаб, до монитора примерно метр. 2 пробела, для меня, более чем достаточно. И в своих пет-проджект я использую те настройки, которые удобны и симпатичны мне.
Эмммм… а разрешение какое? У меня 27’’/4к, до мониторов примерно метр, но с масштабом меньше 150% я ничего не вижу, ЧЯДНТ
Те же 4К. пользуюсь sublime, размер фонта 10, фонт Hack.
Сильно зависит от зрения. В моем случае все ок. Хотя за компом лет с 15.
Сначала это был клон spectrum и был не монитор, а телевизор. Только года с 2000 появился нормальный PC с монитором. И только с 2007 перешел на мониторы с нормальной матрицей.
Видимо просто от природы повезло.
Но мои коменты выше как раз про то, что неправильно всех под одну гребенку.

PS.: очень кстати бесит тенденция делать гигантский шрифт на большом разрешении на сайтах.
Символы табуляции лучше не использовать

Ну да, как же...


"НравиТСЯ". И показываться будет не так как нравится автору, а как будет принято в команде.

Дон Кихот прям какой-то…
вы работали когда то с большими и старыми системами? или системами где используются активно компоненты с открытым исходным кодом? в таких ситуациях везде будет разный стиль, где то нравится где то нет, и чем боротся с ветряными мельницами навязывая свои вкусы пора бы уже повзрослеть и научится читать код с разным кол-ом пробелов. так сказать расслабился и начать работать.

Я никому ничего не навязывал, не навязываю и не собираюсь это делать. Посыл статьи — объяснить о необходимости думать головой, а не надевать трусы не вытерев жопу.

Также отступы следует делать в 4 пробела, так как такой код лучше воспринимается человеческим глазом.
Весьма смелое обобщение.

Символы табуляции лучше не использовать, т.к. на каждом устройстве в каждом окружении может по-разному быть настроен размер табуляции
А вы не задумывались, почему он настраивается?
Возможно, «человеческий глаз» у всех разный?

Хоспаде, дочитайте уже до конца.

Дочитал до конца, дальше вот что:


Размер в два символа лучше не использовать по той причине, что код становится нечитабельным и выглядит как "по линейке" — в одну слегка кривую вертикальную линию. И отследить в таком массиве вложенные операторы становится проблемной задачей.

В чем проблема, что другой будет видеть код таким, каким он привык? Вы считаете, что с 2 пробелами у всех проблема отследить вложенность?
Если у вас проблемы с 2 пробелами, то при использовании табов у вас-то код будет выглядеть так, как вам привычно.
Есть ведь тимлиды, которые считают, что 2 пробела — мало, 4 — много, а 3 — в самый раз. И они с такой же как у вас логикой заставляют всех полюбить 3 пробела.

До конца, это до раздела "заключение" с этим текстом:


P.S.: Уже несколько людей, включая сообщения вне Хабра, написали о том, что есть такие штуки как PSR, автокомплит кода, форматирование кода в IDE, cs-fixer и так далее. Вы правда думаете, что я не знаю о их существовании? Проблема, раскрытая в статье, не в том, что их не используют, а в том, что мешает изначально красиво писать код, не поджигая пуканы других разработчиков?..

В своём посыле я пытаюсь объяснить, что нужно не полагаться на средства разработки, а изначально стараться писать код чисто и не важно сколько в нём пробелов и табуляций. Пример был показан только как пример, но именно на него, почему-то, сагрились почти все комментаторы и здесь, и в чатах. Несмотря на то, что это тупой, блин, пример показывающий всего лишь разницу восприятия, не более.
И что больше всего мне не нравится — 99% комментаторов вообще не поняли смысл написанного, зацепившись, опять таки, за примеры.

Месиво текста надо не отделять переносами строк, а рефакторить. Например, вынести в приватный метод с говорящим названием.

Статья об изначальном написании читаемого кода, а не рефакторинге, слово о котором использовано только в качестве примера.


Ежу понятно, что ide умеет в автоформат, но вопрос в том, что мешает изначально писать нормально?

1. Я немного фулстек, пишу на с# и Typescript. Поэтому дилеммы «скобка на новой строке или на той же» — не стоит. Это ВООБЩЕ не влияет на результат. Пишу и так, и так.
2. Читаемый код не существует в вакууме. Открываешь несколько топовых проектов на конкретном языке в гитхаб, смотришь кодстайл и используешь. Всё. Точка. За тебя придумали — используй. Нонконформизм, типа, мы знаем, как более правильно — не работает. Нужна программа, нужна автоматизация бизнеса, а не сам код в каком-то стиле.
По заголовку статьи можно подумать, что статья не привязана к конкретным ЯП, но это не так. И даже тегов нет
Я бы отрефакторил ваши скобочки!!!
switch($value)

=>
switch ($value)


А вообще для пыхи есть Code Sniffer, установка и использование которого в качестве линтера решает многие стилевые штуки, типа переносов и т.п. Почему-то многие JavaScript-изёры знают и используют ESLint, а вот пыхеры довольствуются стандартными мягкими настройками пыхешторма(

Блок "заключение":


P.S.: Уже несколько людей, включая сообщения вне Хабра, написали о том, что есть такие штуки как PSR, автокомплит кода, форматирование кода в IDE, cs-fixer и так далее. Вы правда думаете, что я не знаю о их существовании? Проблема, раскрытая в статье, не в том, что их не используют, а в том, что мешает изначально красиво писать код, не поджигая пуканы других разработчиков?..

ESLint тоже та ещё муть. Поднимал несколько фронтовых проектов и из коробки он работает отлично, НО вообще не вписывался в кодстайл, установленный нашей командой.
В итоге потратил пару дней на исправление его правил, чтобы работало так, как надо. Первая проблема — заменить 2 символа на 4 в табуляции. И всё. С половину правил нужно переопределять, куря маны.
Вот это действительно зачёсывание разработчиков под одну гребёнку...

для ESLint можно кастомизировать стиль кода, сделать расширение, засунуть его в npm, а затем всю жизнь использовать всей командой, устанавливая двумя строчками.

Говорят, что TSLint однажды пропадёт и останется только ESLint

Можно, но то что нужно наизнанку вывернуться при его настройке, такая себе "коробка".

Честно говоря, второй пример мне был понятнее до рефакторинга.
Почитал комментарии и посмеялся, не часто встречаются холивары одновременно насчет скобок и пробелов/табов, обычно, что-то одно.

В начальной статье я примеры в качестве примеров добавил, а народ посчитал их основной сутью статьи и начал придираться то к скобкам, то к пробелам. Убрал, чтобы не отвлекались более.

Вот порезали вы статью, но только сути это ей не добавило. Той самой сути, про которую народ не читал и начал придираться.
Как вам верно написали IDE сама отформатирует. И есть PSR.
Основные претензии читающих были в том, что советы ваши не как советы оформлены, а как истина в последней инстанции. И не программисты те, кто не делает так же.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.