Ну нет же… Это фрагментация сборки. А что если у вас появится необходимость генерировать спрайты и подставлять их в CSS? А если возникнет задача делать сборку CommonJS? AMD? Как ни крути, эко-система Gulp/Grunt покрывает 100% задач сборки, а ваш вариант, увы, нет. Плюс поддержка и расширение вашего инструмента — то еще приключение для пользователей.
Я понимаю ваше желание найти собственное решение, и это здорово, но попробуйте критически посмотреть на Gulp/Grunt — их использование обойдется гораздо дешевле в долгосрочной перспективе именно благодаря комьюнити, эко-системе, и сотням готовых конфигов.
1. С первым аргументом не соглашусь. Это скорее вопрос запоминания лексических конструкций языка. Я считаю абсолютно нормальным, если я берусь дорабатывать чей-то код и нахожу там какие-то непривычные мне лексемы. Стиль написания кода у всех разный, и я с этим лучше смирюсь, чем решу, что теперь все нужно заново переписать. Да и вообще боттл-нек не тут, если речь о ресурсах на поддержку.
2. Тернарные операторы — это частный случай. С вашей логикой приоритезации согласен. Это нужно понимать, но не более. Если ты не понимаешь тонкости языка, и правда, не стоит лесть в дебри Если ты пишешь интерфейс для тех, кто не понимает — не стоит подвергать их соблазну. Но если с этим проблем нет — то ограничивающий фактор — исключительно командные решения,.
Кроме того, мне кажется, что вы преувеличиваете идеальный код. Это не более чем элементарные вещи: DRY, KISS, настроенный линтинг, стайлгайды, тесты, лаконичные методы и тд. Возможно, это еще и модульность: блек-бокс — это потрясающе — передаешь что-то на вход, получаешь что-то на выходе. Подробности реализации не имеют значения, так как они должны стабильно решать задачи, не более того. Да и в коммерческих проектах идеальный код не всегда возможен — есть задачи, которые нужно было «вчера и на оленях», тут блек-боксы очень помогают.
Даже код в примере (хотя он и в правду наркоманский, и запятая — это очень не ок, а используй concat([item]) вместо push(item) она и не нужна будет) решает свою задачу — показать пример реализации метода, не вдаваясь в подробности.
Стремиться быть всем понятным — это утопия, и лично я против того, чтобы следовать ей. Но стремиться ыть понятным своей команде — это очень важно, и этому следовать нужно.
Абсолютно не соглашусь с вами, во всем, за исключением действительно странного примера с тернарным оператором, тернарность которого тут и правда не нужна. Я убежден, что крокфорданизация JavaScript преследует немного иную цель, нежели писать все согласно заветам, и эта цель — единообразие.
Если команда решает, что нужно по возможности использовать тернарки, то нужно следовать этому. Если команда решает, что нужно использовать лексему `~[].indexOf()` для проверки вхождения — нужно этому следовать. Если в команде принято иначе — нужно придерживаться общих правил.
В JavaScript есть некоторые «неудобные конструкции» — hoisting, автоподстановка точки-с-запятой, которая не срабатывает на строках оканчивающихся или начинающихся на скобочки и операторы, которые могут быть как унарными, так и бинарными. Но все это не значит, что этими штуками грушновато пользоваться. Я считаю это глупым. Посмотрите, сколько команд не используют точку с запятой, посмотрите сколько дейстивительно великолепных JS-разработчиков пишут вызов функций через тернарные операторы. TJ Holowaychuk, Isaac Schlueter, да у каждого состоявшегося разработчика есть предпочтения, и это не просто нормально. Это отлично!
Совершенно не имеет значения, какие лексемы и практики языка использовать, а какие нет, главное, делать это единообразно в рамках всей команды. Если вы не знакомы с побитовым оператором `~` — это значит, что нужно разобраться с ним. Если вы знакомы — в чем проблема запомнить лексему? Научиться практикам команды для начинающего разработчика практически тождественно тому, чтобы запомнить стайлгайд, возможность разобраться с острыми углами стайлгайдов — это комплимент, который вам сделала команда.
Для примера сравните такие конструкции:
function (rights) {
return ~[rights].indexOf('write')
? fs.writeFile(...)
: next(throw new Error());
}
function (rights) {
if ([rights].indexOf('write') !== -1) {
return fs.writeFile(...)
} else {
return next(throw new Error());
}
}
function (rights) {
if ([rights].indexOf('write') !== -1) {
return fs.writeFile(...)
}
return next(throw new Error());
}
По-моему, нет никаких причин, не писать так, как в первом примере, если а) У вас нет желания научиться в тернарные и битовые операторы б) У вас нет договоренности с командой.
В любом случае, указывать другим как писать код — это весело, но нужно иметь свою голову на плечах и понимать причины тех или иных гайдов. А читаемость кода — я понимаю исключительно как единообразный стиль, остальное — комформизм.
//Причем объект который передан первым должен расширяться, вторым объектом
it('should be extend', function () {
var a = { foo: '1' },
b = { bar: '2' };
tools.merge(a, b);
//строгое сравнение по ссылке, убеждаемся что это
//один и тот же объект
a.should.not.equal({ foo: '1', bar: '2' }); // Сравниваем по ссылке с новым объектом? Но ведь даже `{ foo: '1', bar: '2' } === { foo: '1', bar: '2' }` — false. Зачем?
a.should.equal(a); // a === a ? Зачем?
});
Реально интересно было узнать сколько разработчиков прошли через подобное, именно это и хотел видеть в комментариях.
Я писал свою CMS, которая должна была преобразовывать определенную файловую структуру (папки с текстом, с фотками, с PDF и тд) в сайт используя различные представления для разных типов файлов. А до этого писал CMS, которая позволяла писать контент в MarkDown и налету конвертировать его в HTML с заданной темой. А совсем недавно писал очень простой движок для блога на NodeJS (не знаю, считается ли это CMS), но это скорее для того, чтобы объяснить, как работает ExpressJS, чем ради написания CMS
Я думаю, что все это полезный опыт: я научился лучше программировать, я научился более-менее сносно рисовать дизайны, ну и начал немного думать о том, что если собираться спустить кучу времени на какой-нибудь проект — стоит подумать, как с этого заработать (опыт, деньги и тд).
Да, автор называет это статьей, но, для удобства публикации и перевода, мы разбили текст на части, и назвали их главами, и эту большую статью мы соответственно назвали книгой. Но вообще, эта статья у автора находится в разделе «MY FREE BOOKS & GUIDES».
Я понимаю ваше желание найти собственное решение, и это здорово, но попробуйте критически посмотреть на Gulp/Grunt — их использование обойдется гораздо дешевле в долгосрочной перспективе именно благодаря комьюнити, эко-системе, и сотням готовых конфигов.
2. Тернарные операторы — это частный случай. С вашей логикой приоритезации согласен. Это нужно понимать, но не более. Если ты не понимаешь тонкости языка, и правда, не стоит лесть в дебри Если ты пишешь интерфейс для тех, кто не понимает — не стоит подвергать их соблазну. Но если с этим проблем нет — то ограничивающий фактор — исключительно командные решения,.
Кроме того, мне кажется, что вы преувеличиваете идеальный код. Это не более чем элементарные вещи: DRY, KISS, настроенный линтинг, стайлгайды, тесты, лаконичные методы и тд. Возможно, это еще и модульность: блек-бокс — это потрясающе — передаешь что-то на вход, получаешь что-то на выходе. Подробности реализации не имеют значения, так как они должны стабильно решать задачи, не более того. Да и в коммерческих проектах идеальный код не всегда возможен — есть задачи, которые нужно было «вчера и на оленях», тут блек-боксы очень помогают.
Даже код в примере (хотя он и в правду наркоманский, и запятая — это очень не ок, а используй concat([item]) вместо push(item) она и не нужна будет) решает свою задачу — показать пример реализации метода, не вдаваясь в подробности.
Стремиться быть всем понятным — это утопия, и лично я против того, чтобы следовать ей. Но стремиться ыть понятным своей команде — это очень важно, и этому следовать нужно.
Если команда решает, что нужно по возможности использовать тернарки, то нужно следовать этому. Если команда решает, что нужно использовать лексему `~[].indexOf()` для проверки вхождения — нужно этому следовать. Если в команде принято иначе — нужно придерживаться общих правил.
В JavaScript есть некоторые «неудобные конструкции» — hoisting, автоподстановка точки-с-запятой, которая не срабатывает на строках оканчивающихся или начинающихся на скобочки и операторы, которые могут быть как унарными, так и бинарными. Но все это не значит, что этими штуками грушновато пользоваться. Я считаю это глупым. Посмотрите, сколько команд не используют точку с запятой, посмотрите сколько дейстивительно великолепных JS-разработчиков пишут вызов функций через тернарные операторы. TJ Holowaychuk, Isaac Schlueter, да у каждого состоявшегося разработчика есть предпочтения, и это не просто нормально. Это отлично!
Совершенно не имеет значения, какие лексемы и практики языка использовать, а какие нет, главное, делать это единообразно в рамках всей команды. Если вы не знакомы с побитовым оператором `~` — это значит, что нужно разобраться с ним. Если вы знакомы — в чем проблема запомнить лексему? Научиться практикам команды для начинающего разработчика практически тождественно тому, чтобы запомнить стайлгайд, возможность разобраться с острыми углами стайлгайдов — это комплимент, который вам сделала команда.
Для примера сравните такие конструкции:
По-моему, нет никаких причин, не писать так, как в первом примере, если а) У вас нет желания научиться в тернарные и битовые операторы б) У вас нет договоренности с командой.
В любом случае, указывать другим как писать код — это весело, но нужно иметь свою голову на плечах и понимать причины тех или иных гайдов. А читаемость кода — я понимаю исключительно как единообразный стиль, остальное — комформизм.
Простите за некрофилию, конечно.
Это очень странно. Возможно, отправляя ответ клиенту, вы вызываете `next()` в обработчике? Можете показать пример, который к этому приводит?
Я писал свою CMS, которая должна была преобразовывать определенную файловую структуру (папки с текстом, с фотками, с PDF и тд) в сайт используя различные представления для разных типов файлов. А до этого писал CMS, которая позволяла писать контент в MarkDown и налету конвертировать его в HTML с заданной темой. А совсем недавно писал очень простой движок для блога на NodeJS (не знаю, считается ли это CMS), но это скорее для того, чтобы объяснить, как работает ExpressJS, чем ради написания CMS
Я думаю, что все это полезный опыт: я научился лучше программировать, я научился более-менее сносно рисовать дизайны, ну и начал немного думать о том, что если собираться спустить кучу времени на какой-нибудь проект — стоит подумать, как с этого заработать (опыт, деньги и тд).