Website development
JavaScript
Programming
Development Management
Comments 23
+1
Можно, кстати, в комментариях общими усилиями придумать как правильно должна быть оформлена эта функция. У неё маленькая цикломатическая сложность, она сама по себе не большая, но как она должна быть оформлена? PixiJS это надо сказать граф движок, 2D но всё-же, так что это проект в котором много сложного кода, и выкинуть его из проекта не получится.
0

Так и должна быть оформлена, на JS, как и на Си, особо не разгуляешься.


На каком-нибудь С++, C# или Rust надо делать типы Point и Vector с переопределёнными арифметическими операторами, это уменьшит число строк вдвое с увеличением понятности.

0
просто популярны аргументы типа: слишком сложно, нужно разбить на понятные фрагменты и функции. И вообще, что это вы тут удумали, алгоритмы писать, есть же готовые. Меня как разработчика работающего с компиляторами и граф движками неимоверно бесит такой подход.
0
До того как линтер заставил разработчика напихать в код скобок, этот код был более читаем. А когда разработчика заставили напихать скобок, он и напихал и линтер успокоился.
+6
Линтер — он настраиваемый. Если проблема с кодом после линтинга, это фейл ответственного за настройку линтера, а не баг линтера. Если у кодера нет возможности просигналить, что линтер криво настроен, это фейл тимлида. Ну и так далее.

Пример из проекта под рукой:
    "no-mixed-operators": [
      "warn",
      {
        "groups": [
          ["&", "|", "^", "~", "<<", ">>", ">>>"],
          ["==", "!=", "===", "!==", ">", ">=", "<", "<="],
          ["&&", "||"],
          ["in", "instanceof"],
        ],
        "allowSamePrecedence": false,
      },
    ],

MIT License.
Пожалуйста.
0
Так нет, проект и считает что так нормально. Т.е. они и хотели так расставлять скобки. На линтер то я не наезжаю, он отработал ровно как настроен. Весь смысл поста в том какие-бы мы правила не настроили, включив линтинг в пре мердж степ мы получим полное соблюдение правил во всём проекте, но толку от этого может оказаться не так много как хочется.
+5
Смысл хотеть от инструмента толку, под который он не создавался?
0

Очень соглашусь. Автор приписывает инструменту качества, которыми он не обладает. Соответственно и выводы несостоятельны.

+3

Всё это полная чушь.


Линтеры, которые следят почти исключительно за оформлением кода — просто слабые. Их слабость может быть вызвана сложностью/гибкостью языка, который слишком сложно анализировать, но это ничего не меняет — существуют линтеры, по крайней мере в других языках, которые способны на очень многое помимо проверки оформления кода.


Если Вы способны отличить плохой код только по косвенному признаку (плохое оформление), то у меня для Вас печальная новость: делать ревью Вам ещё рановато. Да, требование запускать линтер приводит к тому, что и хороший и плохой код выглядит одинаково… но нет, это не мешает, а помогает при ревью, потому что легче сосредоточиться на том, что и как этот код делает, не отвлекаясь на то, как он оформлен.


И, как Вам уже ответили выше, если следование требованиям линтера приводит к ухудшению читабельности кода, то им не надо следовать — надо или менять настройки линтера, или отключать его (в идеале — только мешающее правило, а не весь линтер) локально для данной строки/блока/функции (обычно это делается комментарием в определённом формате).

+1
Линтеры имеют крайне куцые настройки. В итоге пол файла утыкано комментариями для линтера, которые конечно же ни сколько не мешают читать код, в отличие от лишнего пробела рядом со скобочкой.
0

Зависит от качества линтера. Например, в среднем проекте на Go (около 50к строк) у меня директивы для линтера встречаются один раз на 488 строк, в мелком проекте на Perl (около 2к строк) они встречаются один раз на 89 строк. В обоих случаях чтению кода они совершенно точно не мешают.

0
Скорее от притязательности разработчика.
Ну конечно не мешает. Любителям линтеров даже лишний пробел мешает читать код. Что уж говорить про целые строки комментариев врезанные по среди логики. А если вам не мешает, так вам и линтер не нужен. Вы видимо обладаете навыком чтения кода игнорируя лишнее.
+1
Он будет мимикрировать под хороший

Код хороший, когда он читается легко.

Правильное форматирование — только одно из условий, хоть и обязательное.

Отсутствие ошибок линтера — только одно из условий, хоть и обязательное. Без него с ростом кодовой базы в ошибках утонут и перестанут их исправлять. Кстати, в линтере есть опция игнорировать строчку.

В примере выше, раз команда не может прочитать код, то код для команды плохой.

Для этого после фазы линтинга идёт фаза ревью. Не смог ревьюер прочитать — на переделку. Вполне возможно, на переделку нужно отправить не код, а конфиг линтера. Ну либо самого ревьюера.
+1
Про условия вы правильно говорите. Основной посыл тут скорее в законе Гудхарта. Иначе получается карго культ «давайте форматировать ради форматировать». Как итог всё отформатировано, а что получилось пофиг. Да код должен быть отформатирован. Но форматирование это следствие а не причина хорошего кода. Это примерно как лечить лихорадку прикладыванием льда. Да, иногда так и нужно делать, но не всегда.
-1
Вполне возможно, на переделку нужно отправить не код, а конфиг линтера.

А вы когда-нибудь пробовали продавить изменения в конфиг линтера не будучи при этом тимлидом?


Ну либо самого ревьюера.

А вы когда-нибудь пробовали изменить представление человека о хороших и плохих практиках не будучи при этом его прямым руководителем?

+2
Ну да, а что?
1) иногда успешно,
2) иногда неуспешно,
3) иногда успешно после достаточно продолжительного промежутка времени для обдумывания аргументов,
4) иногда успешно после достаточно продолжительного промежутка времени и предоставления возможности людям самим наступить на свои грабли,
5) иногда неуспешно после достаточно продолжительного промежутка времени чтобы понять, что человек был прав,
6) иногда неуспешно после достаточно продолжительного промежутка времени чтобы понять, что, оказывается, те же яйца в профиль,
7) один раз уволился по собственному желанию.
С течением старения доля и количество 1) постепенно растёт. Правда, не сказал бы, что старение — адекватная плата за эффект :(
0
Отсутствие ошибок линтера — только одно из условий, хоть и обязательное

Именно. Это лишь необходимое условие. А автор подумал, что оно же и достаточное. :)

0

Статья как раз о том, что как раз не достаточное. Но, к сожалению, многие люди думают что достаточное. Только моя позиция в том что это не условие, а следствие.

+9
Из всей статьи я только вижу проблему в том, что функция не покрыта тестами. А линтер и скобки тут вообще нипричем.
+1
1. Там продавец красивая, а у нас баба Маня вышла на подмену...

Макдональдс копнули глубже.
С красивыми девушками болтают больше – следующие покупатели ждут дольше.
С баб Манями болтают дольше – следующие покупатели ждут дольше.
С женщинами вообще…
Мак нанимал в официантки и поварихи только яценосителей!
Зарплаты были чуть пожирнее, но это было так наркотически выгодно, что, естественно, даже запретили законом.
+1
мне кажется, одной из проблем является то, что автор коммита прогуливал математику в школе.
0
Есть одна проблема. Этот код делает полную херню.

Спасибо, сделало мой вечер
Only those users with full accounts are able to leave comments.  , please.