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

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

Верно, хватает тех, кто забывает работает в команде, и что кто-то еще кроме него будет работать с его кодом.
Я, за свою долгую карьеру, понял одно, нету глобального понятия «Чистый код», есть стандарты в фирме, которой ты работаешь, и именно их и нужно использовать, что бы код выглядел одинаково, а так же что бы каждый программист в данной фирме смог разобрать твой код.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
MyComponent = ({ placeholder = '', style, <b>...otherProps </b>}) => {

style={{
        border: `1px solid ${placeholder ? 'salmon' : '#333'}`,
        <b>...style</b>,
      }}
      {<b>...otherProps</b>}

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

} from '../../../../../../../../../../components/Breadcrumb'
render={(results) => (
        <BreadcrumbFishes>
          {({ breadcrumbFishes }) => (
            <BreadcrumbLeftOvers.Provider>
              <BreadcrumbHotdogComponent>
                <Expander>
                  <BreadcrumbText>
                    <BreadcrumbAddict>

весело тем кто будет разбираться в таком коде :)
../../../../../../../../../../

Это шутка?
Не знаю насколько это шутка в статье, но я лично встречал проекты с таким издевательством :)
Увы, абсолютные пути в импортах — это еще большее издевательство, которое легко отказывается работать в самые непредсказуемые моменты (корень не там, один из инструментов считает, что корень не там, код перенесен, типы TS вдруг отпали, и всё в таком духе).

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

...
<BreadcrumbAddict>
   <pre>
     <code>{JSON.stringify(results, null, 2)}</code>
   </pre>
</BreadcrumbAddict>


Может лутше подготавливать все данные заранее?
И вообще, Вы веть должны понимать — react (как и vue, svelte, etc.) лиш «рисовалка», и гораздо важнее уметь правильно разделять приложение на независимые слои, с минимальными «точками соприкосновения», про это уже писали, правда не в контексте «фронтэнда».
НЛО прилетело и опубликовало эту надпись здесь

Если правильно понял то вам нужен этот пакет ️ https://github.com/pahen/madge


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

НЛО прилетело и опубликовало эту надпись здесь
Написание чистого кода (...) становится обязательным на определённом этапе карьеры программиста. Особенно (...) когда программист пытается найти свою первую работу.

Нууу, удачи, как говорится, всем студентам писать чистый код еще до своей первой работы… :)
let result
if (variant === 'h1') result = styles.h1
else if (variant === 'h2') result = styles.h2
else if (variant === 'h3') result = styles.h3
else if (variant === 'h4') result = styles.h4
else if (variant === 'h5') result = styles.h5
else if (variant === 'h6') result = styles.h6
else if (variant === 'title') result = styles.title
else if (variant === 'subheading') result = styles.subheading

O_o не делайте так никогда, это пример плохого кода. Используйте switch в подобных конструкциях.


const getStyles = variant => {
  switch (variant) {
    case 'h1':
      return styles.h1
    case 'h2':
      return styles.h2
    default:
      return styles.default
   }
}

const getStyles = variant => (variant in styles ? styles[variant] : null)


После подобного и ../../../../../../../../../../, невозможно воспринимать статью всерьёз. Webpack alias, автору для справки.
Webpack alias, автору для справки.

Вы только не забывайте, что про webpack alias будет знать только вебпак. А не, например, IDE.

const getStyles = variant => (variant in styles? styles[variant]: null)

А потом этот код попадёт под минификацию и станет тыквой. Switch — нормально во всех случаях, а вот этот вариант — далеко не во всех.
А потом этот код попадёт под минификацию и станет тыквой.

Если ваша минификация калечит даже такой код, то первое что вам стоило бы сделать — поднастроить её или удалить к чертям. У всего есть свои пределы. Минификация не должна влиять на то, как вы пишете код. Ну за редким исключением вроде штук вида dead code elimination.

ваша минификация

Вы из тех, кто кроме готовых сайтиков всей кучей никогда ничего не писал?
Проблема кривой минификации может быть совсем даже не у вас, вот в чём соль. А у людей, использующих ваш код. И не всегда это такие люди, которым можно сказать «проблема на вашей стороне».

Сделать всё как надо у вас — никогда не проблема, во фронтэндском CI настраивается примерно всё, а если вдруг не настраивается, то есть другие инструменты, где таки да. А вот сделать так, чтоб ваше творение жило и работало во всех сценариях использования, в том числе не ваших, и в том числе и не особо правильных — это чуточку другой разговор.

Какой-то нелепый переход на личности (рекомендую так больше не делать здесь) и несвязный текст. Что вы хотели сказать? Поясните детальнее. Моя позиция простая: минификация кода (uglifyjs наверное в вашем случае) НЕ ДОЛЖНА ломать код. Т.е. не должна переименовывать литералы и не должна переименовывать ключи объектов. Если она так делает, то она сильно агрессивная и ломает работу тех продуктов где используется (пока разработчики не выловят сами все эти проблемные места). У вас есть по этому поводу возражения?


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

Какой-то нелепый переход на личности

Да ровно такой же, каков и ваш.

Что вы хотели сказать? Поясните детальнее.

Поясняю по буквам: пайплайн сборки не всегда полностью у вас под контролем, иногда его часть на стороне.

Если она так делает, то она сильно агрессивная и ломает работу тех продуктов где используется (пока разработчики не выловят сами все эти проблемные места). У вас есть по этому поводу возражения?

У меня — нет. Возражения могут быть у тех, кому, например, вы поставляете вашу либу. А на ваши заявления о том, что они сами виноваты — они всегда могут ответить «нет, не мы», и не всегда у вас будет возможность продолжать эту линию аргументов.
Вы так не делали и у вас подобных случаев не возникало? Ну поздравляю.

Т.е. я не против того чтобы минификатор менял длинные имена на короткие двубуквенные, но он должен делать это ТОЛЬКО и ТОЛЬКО тогда когда он гарантирует тот факт, что это ничего не поломает в коде.

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

Нет, нельзя. Достаточно сократить до двух букв какой-нибудь window или document — и всё поломается как бы вы не писали код.

Окей, принимается.

Можно написать так, что минификатор JS-кода для известного контекста в принципе ничего не поломает (с какими угодно настройками).

Так ведь известный контекст тоже может быть настройкой!

А я вам о том, что минификатор не всегда на вашей стороне.

Нет никаких объективных причин принимать в рассчёт такие случаи, когда на чужой стороне стоит неадекватно настроенный минификатор, который ломает даже такие тривиальные случаи.


Ну, ок, исключение — когда вы пишете B2B продукт под конкретную контору, где время остановилось, страшное легаси и жуткая бюрократия, поддержка IE8 & Silverlight. В этом случаем это наименьшая из ваших проблем да.


Вы так не делали и у вас подобных случаев не возникало?

Я вам даже больше скажу — и никогда не возникнет. Подобными извращениями ("перетюненный" uglifyjs) баловались люди года 4 назад. У них стали ломаться ангуляры и тонны других библиотек. Потом пришло осознание простой истины — сама затея пережимать ломая код идиотична по своей природе.


P.S. предлагаю на этом наш "холивар" закончить. Ваша точка зрения мне более чем понятна.

Ну, ок, исключение — когда вы пишете B2B продукт под конкретную контору, где время остановилось, страшное легаси и жуткая бюрократия, поддержка IE8 & Silverlight. В этом случаем это наименьшая из ваших проблем да.

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

P.S. предлагаю на этом наш «холивар» закончить.

Надо же, людям пишешь «позвольте, но не всегда всё так просто, как вы считаете», а они это холиваром потом называют.

Почему бы не упростить вот так:


const result = styles[variant];

У автора написано вот такое:


const removeFalseyImages = (images = []) =>
images.reduce((acc, img) => (img ? [...acc, img] : acc), [])

Но я но согласен! Такое нужно переписать вот так


const removeFalseyImages = (images = []) => images.filter(Boolean);
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации
Представитель
ruvds

Блог на Хабре