Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 89
На мой взгляд, в данном случае использование обычного if будет меньше загромождать код и сделает его более понятным.
Имхо, если функций 2-3, и они имеют понятные и не очень длинные названия, то с тернарным код более читаемый.
Он ужасен не тем, что длинный или нечитаемый, а потому что Вы используете операторы не для того, для чего они предназначены. Если бы я встретил в коде exec1() && exec2() && exec3() я бы совершенно справедливо усмотрел там управление логикой.
Понять на лету, что это это просто такое хитрое последовательное выполнение и что для Вас нормальное поведение этого оператора это "крупный недостаток" , мне представляется сложным.
Понять на лету, что это это просто такое хитрое последовательное выполнение и что для Вас нормальное поведение этого оператора это "крупный недостаток" , мне представляется сложным.
Уж извините, но такое использование операторов — это не криминал. Как вы делаете подстановку значения по умолчанию? так: var f = func() || 'default'? Или расписываете if проверку? Чем тогда страшно exec1()|exec2()|exec3()? Кстати, если так не нравится применение логических операций используйте запятую... приведен же этот вариант.
Тем, кого заинтересовала эта статья, советую почитать статьи Дмитрия Котерова Маленькие хитрости JavaScript и Большие хитрости JavaScript
За такое «раширенное применение тернарного оператора», будь то JavaScript, C++ аль PHP, надо отлучать от программирования на неделю.
Чем вам if не угодил? А ведь кому-то этот код читать!
Чем вам if не угодил? А ведь кому-то этот код читать!
Такое «применение» тренирует гибкость мышления ;) Увы, если постоянно думать о том, что за тобой будут этот код «читать», то дальше «Hello world» никуда не уйдешь. У каждого должна быть своя песочница... вот вам примерчик из Query (он упоминается в англ.статье):
function findActive(selector) {
return selector != undefined
? typeof selector == “number”
? headers.eq(selector)
: headers.not(headers.not(selector))
: selector === false
? jQuery(”")
: headers.eq(0)
}
function findActive(selector) {
return selector != undefined
? typeof selector == “number”
? headers.eq(selector)
: headers.not(headers.not(selector))
: selector === false
? jQuery(”")
: headers.eq(0)
}
извините jQuery
нормальный код, хотя отформатирован не верно :)
Простите, но вот мне как-то удаётся писать приложения больше, чем «Hello world», и при этом думать о других.
не круто, дальнейшая поддержка кода должна быть обязательно, ну короче develop7 полностью прав, а при промышленном производстве такой подход - это вообще бред, один написал гкод, через год его начинает читать другой, выбрасывает, пишет свой гкод и т.д., не эффективно ниразу
Ребята, хватит уже по эффективность и читабельность! Все уже все поняли и накатали монументальные труды про то, как надо правильно думать за «вследидущем». Хватит!
Не надо применять тернарный оператор, это сложно, не нужно замыканий, это сложно, забудьте о прототипах это сложно, это сложно, это трудно читать, __proto__ а что это? Нет, студент Вася не поймет, жалко его у нас же промышленное производство а не кустарный труд ;)
Не надо применять тернарный оператор, это сложно, не нужно замыканий, это сложно, забудьте о прототипах это сложно, это сложно, это трудно читать, __proto__ а что это? Нет, студент Вася не поймет, жалко его у нас же промышленное производство а не кустарный труд ;)
Сходил почитал оригинал, резюме: автор плавает, пока ещё плохо знает язык, но уже пишет по мотивам своих лабораторных опытов. Ничего не имею против n00bs и их широко открытых глаз, но на мой взгляд, нести чужую аГлицкую песочницу на хабр - это перебор. Его там и свои отлупят... за "bad code" и проч. беллетристику.
Я узнал из статьи что-то новое и решил написать статью по мотивам, т.е. не перевод, а попытка своими словами описать. А на счет переноса чужих «песочниц» так это итак сплошь и рядом ибо крайне удобно прикрываться чужим авторством... типа я только перевел текст, все вопросы к автору родительской статьи.
P.S. кстати, у вас намечается злоупотребление словами «плавает» и «bad code» ;)
P.S. кстати, у вас намечается злоупотребление словами «плавает» и «bad code» ;)
Да, злоупотребляю, люблю знаете ли это дело ;)
Что-то новое - это видимо:
про существование "comma operator" я вообще не знаю, поэтому два выражения, оказывается, можно засунуть в функцию (вау!), а ещё лучше для этого дела использовать "binary bitwise operator" (мама!), и вообще, братцы, на "conditional operator" можно легко заменить не только -if/else- , а и -if- тоже, пускай там на хвостике нолик болтается, зато какая красивая запись получается в итоге:
condition == true ? foo()| bar()| something() : 0;
p.s. это чего за код такой, неужели не видите неуместное использование "equals operator", абсолютно неуместное использование "binary bitwise operator" и совершенно дурацкое использование "conditional operator" в стиле эмуляции "if statement" без -else-?
Что-то новое - это видимо:
про существование "comma operator" я вообще не знаю, поэтому два выражения, оказывается, можно засунуть в функцию (вау!), а ещё лучше для этого дела использовать "binary bitwise operator" (мама!), и вообще, братцы, на "conditional operator" можно легко заменить не только -if/else- , а и -if- тоже, пускай там на хвостике нолик болтается, зато какая красивая запись получается в итоге:
condition == true ? foo()| bar()| something() : 0;
p.s. это чего за код такой, неужели не видите неуместное использование "equals operator", абсолютно неуместное использование "binary bitwise operator" и совершенно дурацкое использование "conditional operator" в стиле эмуляции "if statement" без -else-?
На вкус и цвет все фломастеры разные. Если вам не нравятся описанные вещи то это ваша личная проблема-радость-счастье (выбрать нужное). Я предложил способ, чужой способ, который мне понравился, но рассусоливать причины почему это не нравится другим, извините, скучно... если я бы знал вас как профессионала и уважал ваше мнение специалиста в этом вопросе, то это бы меняло расклад, а сейчас это просто нелепый спор и бряцание познаниями.
Вы все это знали? Я рад за вас! Но большинству это по-барабану.
Почему бы вам не взять и не написать статью про ваши наработки и лабораторные работы с чужими структурами? Или о уместных и неуместных использованиях... провести работу над частыми ошибками и заблуждениями?
Только обхаивая труд других в комментариях авторитета и уважения не добъешься.
P.S. «неужели не видите неуместное использование "equals operator"» если бы видел подобное, то не писал бы. Почему нестандартное применение считается вами «неуместным»?
Вы все это знали? Я рад за вас! Но большинству это по-барабану.
Почему бы вам не взять и не написать статью про ваши наработки и лабораторные работы с чужими структурами? Или о уместных и неуместных использованиях... провести работу над частыми ошибками и заблуждениями?
Только обхаивая труд других в комментариях авторитета и уважения не добъешься.
P.S. «неужели не видите неуместное использование "equals operator"» если бы видел подобное, то не писал бы. Почему нестандартное применение считается вами «неуместным»?
да, с condition == true автор погорячился, возможно чтобы показать сам факт условия, но в моем варианте этого нет.
«абсолютно неуместное использование "binary bitwise operator"» тут вопрос как раз в отношении к нестандартным решениям.
«и совершенно дурацкое использование "conditional operator"» а это тем более субъективно.
«абсолютно неуместное использование "binary bitwise operator"» тут вопрос как раз в отношении к нестандартным решениям.
«и совершенно дурацкое использование "conditional operator"» а это тем более субъективно.
Чтоб быть до конца понятым, тернарный сам по себе - это есть хорошо, удобный, компактный оператор. Плохо, когда его начинают использовать в качестве ИФозаменителя, когда при false впустую/неуместно вычисляется какой-нибудь литерал вроде null или 0. Интерпретатор делает ненужную хоть и копеечную работу только для того, чтобы ваше выражение работало. Это к вопросу о "дурацком использовании". Что касается "bitwise", то автор это чудо родил по той причине, что он просто не знает должным образом операторов javascript или выражений, которые могут выполнить ту же задачу. Отсюда и это "нестандартное" решение. С "condition==true" вы уже сами поняли идею...
Уважаемый, вы не правы. Поверьте, опыта у Zeroglif в данной области куда больше вашего (знаю не по наслышке), и ваш довод "не нравятся описанные вещи то это ваша личная проблема" абсолютно некорректен. Не надо учить потенциальных программистов изначально делать ошибки. Статья ради статьи не есть хорошо, а использование бинарных операторов в вашем случае действительно неуместно.
Пожалуйста, не стоит переходить на личности, какая сейчас разница, кто стоит за ником. Ни мне нет до этого дела, ни вам не должно быть. Это в плане уважения мнения и проч. Теперь о каком охаивании труда вы говорите? Дело даже не в охаивании, а в труде. Вот эта вот коротенькая заметка по мотивам, наполненная сомнительными выводами - это считается трудом? Нельзя этот труд комментировать в критическом ключе? Виноват, больше не буду... ;)
Поправьте, пожалуйста: парсер -> интерпретатор.
Парсер код разбирает лексически и на основе разбора формирует в памяти удобные для выполнения структуры. Потом их читает интерпретатор и, собственно, выполняет.
Парсер код разбирает лексически и на основе разбора формирует в памяти удобные для выполнения структуры. Потом их читает интерпретатор и, собственно, выполняет.
А в обычной жизни вы на перле программируете, наверно? Любят перловики такие извращения :))
Есть оператор if, им и надо пользоваться в данном случае.
Есть оператор if, им и надо пользоваться в данном случае.
нет, пишу не только на perl-e, вернее на нем практически не пишу. Люблю красивый, компактный и логичный код даже если он вызывает трудности у 90% читающих ;) Поэтому если нужно, то будет и if-else.
Сравните:
if (condition) {
this.doThis();
} else {
this.doThat();
}
и
this[condition ? 'doThis' : 'doThat']();
Сравните:
if (condition) {
this.doThis();
} else {
this.doThat();
}
и
this[condition ? 'doThis' : 'doThat']();
По-моему, код в первую очередь должен быть понятным, в том числе самому через пару лет. "Изящность" взамен понятности допустима, скажем, в высоконагруженных системах, или в каких-нибудь демках типа 4Kintro на ассемблере (интересно, щас их кто-нибудь пишет еще?). Да и то, если это дает реальный прирост производительности.
Пишут-пишут и 4k и 256b. Интересно, а кому тогда нужна «понятность»? Я работаю в команде и еще, тьфу-тьфу, не сталкивался со случаем, когда напарники ссылались на непонимание описанных структур... если ими не пользоваться, то и читаться они будут с трудом, если же они сплошь и рядом то и воспринимаются на ура.
Поддерживаю, хотя я постоянно пишу на Perl.
Компактный и красивый код - всегда будет компактным и красивым, если через некоторое время ты сам не понимаешь, значит приложил не все усилия, чтобы сделать код таковым!
Перфекционизм - вот залог успеха в программирование.
Плюс почти всегда красивый код работает быстрее :) (если это в вашем языке не так, то скоро будет).
А на счет написать if-else вместо тернарного оператора - должно быть оправданно.
Вот пример:
вот здесь писать if-else не разумно, а вызывать функцию, где будет if-else, н-р, нет возможности, поэтому решение - тернарный оператор.
Нужно все использовать с умом,
тогда код будет и быстрым, и красивым.
Компактный и красивый код - всегда будет компактным и красивым, если через некоторое время ты сам не понимаешь, значит приложил не все усилия, чтобы сделать код таковым!
Перфекционизм - вот залог успеха в программирование.
Плюс почти всегда красивый код работает быстрее :) (если это в вашем языке не так, то скоро будет).
А на счет написать if-else вместо тернарного оператора - должно быть оправданно.
Вот пример:
onClick="..."
вот здесь писать if-else не разумно, а вызывать функцию, где будет if-else, н-р, нет возможности, поэтому решение - тернарный оператор.
Нужно все использовать с умом,
тогда код будет и быстрым, и красивым.
Что такое "красивый код"? У каждого свои представления о красоте. Для написавшего он будет красив, а для читающего - полная лабуда, в которую надо вникнуть, потратив на это энное количество минут или даже часов. Поэтому, если код пишется просто для себя, то можно, конечно, любоваться и говорить "Ай да я, ай да сукин сын", а когда идет работа в команде, и твой код будет кто-то потом ковырять и дорабатывать, то залог успеха - писать по всем понятным стандартам и не вы..ваться :))
Команда сама может устанавливать стандарты. Если в ней есть «слабое звено», которое по полчаса всматривается в чужой код, то это проблема не языка и методов ;). Кстати, «сложные» тернарные конструкции чаще всего появляются на этапе оптимизирования кода когда изначальная груда строчек if-else структуры сводится в одну строчку с возможным исключением лишнего. И, согласитесь, работать после специалиста-оптимизатора может только программист с не худшим уровнем, т.е. все прекрасно поймется.
если стандарт из-за не умения программировать падает, до уровня - создадим десяток переменных, чтобы было понятно школьнику, то это ваше дело.
В каждом языке есть стиль и красота, так вот их нужно придерживаться. Если кто-то это не понимает, то ему нужно повысить свой уровень! Другими словами - должен быть барьер понимания.
Пример - не каждый может понять математический анализ, но стоит его поучить и все станет на свои места!
В каждом языке есть стиль и красота, так вот их нужно придерживаться. Если кто-то это не понимает, то ему нужно повысить свой уровень! Другими словами - должен быть барьер понимания.
Пример - не каждый может понять математический анализ, но стоит его поучить и все станет на свои места!
По-вашему, показатель крутости программиста - это умение применять и придумывать причудливые конструкции данного конкретного языка? Я так не считаю.
ключевое - умение применять синтаксические, лексические и прочее конструкции языка.
Это означает владение языком.
Пример - зная алфавит русского языка, не возможно начать на нем говорить, пока не выучишь основные правила. Лингвист "крут", если знает большое количество оборот, морфологию языка, ... и самое важное - умеет это красиво применить, т.е. сказать.
Это означает владение языком.
Пример - зная алфавит русского языка, не возможно начать на нем говорить, пока не выучишь основные правила. Лингвист "крут", если знает большое количество оборот, морфологию языка, ... и самое важное - умеет это красиво применить, т.е. сказать.
Лингвист крут, когда знает общие особенности групп языков, а не все слова и выражения конкретного языка. Так же и в программировании: крут не тот, кто знает все фичи языка, а тот, кто умеет делать качественный продукт, независимо от языка. Качественный не только для пользователей (то есть отсутствие ошибок, удобство в работе), но и внутренне - а это в первую очередь удобочитаемость кода.
Я в принципе согласен с вашим посылом, но удобочитаемость не должна рулить. Тернарный оператор или та же запятая - это удобные и понятные операторы, для профессионала они, в принципе, не должны снижать читабельность, отказываться от них глупо. Проблема в программировании ради красоты/компактности/понтов, когда оператор верный а место, куда его засунули чужое.
удобочитаемость должна быть в разумных пределах.
нужно для себя определить, что значит "удобочитаемость".
Для меня лаконичный и красивый код всегда удобочитаемый, обратное не верно.
Как я понимаю, ваша удобочитаемость сводится к максимальной расписки простых вещей, наверня-ка, вы не используете цепочки, tips & tricks и hacks тоже.
Это все ведет к тоvу, что код становится очень длинным.
Из-за того, что код понятен даже новичку, при чтение его можно потерять мысль, проматывая экраны "удобочитаемого" кода.
Если бы в математике все расписывали словами и не использовали краткие записи, то все книги по математике увеличились бы в 10-ки, а-то и в 100-ни раз!
нужно для себя определить, что значит "удобочитаемость".
Для меня лаконичный и красивый код всегда удобочитаемый, обратное не верно.
Как я понимаю, ваша удобочитаемость сводится к максимальной расписки простых вещей, наверня-ка, вы не используете цепочки, tips & tricks и hacks тоже.
Это все ведет к тоvу, что код становится очень длинным.
Из-за того, что код понятен даже новичку, при чтение его можно потерять мысль, проматывая экраны "удобочитаемого" кода.
Если бы в математике все расписывали словами и не использовали краткие записи, то все книги по математике увеличились бы в 10-ки, а-то и в 100-ни раз!
Владеть языком - это же не значить балаболить в стиле Отара Кушинашвили, где он красиво использует 3 предложения и 4 деепричастных оборота, чтобы сказать "молоко". Владеть языком нужно адекватно поставленной задаче, если вместо ясной и адекватной задаче конструкции -if- начинают использовать в режиме statement тернарный оператор, где false-выход забивается "пустым" значением только для того, чтобы работало, то попробуйте объяснить, где тут смысл и в чём глубокая идея. Я уже молчу про остальные "красиво применённые" конструкции в этой заметке.
Плохой пример.
Не
Не
onClick="...", а element.addEventListener('click',doSomething,false).это еще почему?
в самой обычной ситуации, я не собираюсь писать отдельный скрипт или втавку, в котором я повешу слушателя на нажатие на ссылку.
Не нужно ничего усложнять!
в самой обычной ситуации, я не собираюсь писать отдельный скрипт или втавку, в котором я повешу слушателя на нажатие на ссылку.
Не нужно ничего усложнять!
Если вы пишете скрипт для себя, на коленке, то делайте что угодно.
Но если делаете проект, знаете MVC, то складываете эти вещи в разные места.
Но если делаете проект, знаете MVC, то складываете эти вещи в разные места.
Тотальное игнорирование культуры программирования.
Короче != лучше.
Ужасный пример.
Короче != лучше.
Ужасный пример.
особой пользы не нашел для себя, но всё равно занятно
спасибо!
спасибо!
Прямо какая-то беда с этими публикациями. Как название статьи? «Расширенное применение тернарного оператора» заметьте не «правильный стиль офрмления», «легкость понимания» и т.д. а просто дополнительный способ использования оператора. Применять или не применять его — это личное дело разработчика или команды разработчиков.
И какая разница как вы пишете так:
или так:
или так:
Речь ведь не об этом! А теперь еще раз прочитаем название статьи.
Спасибо за внимание.
И какая разница как вы пишете так:
if (condition) {
exec1();
exec2();
exec3();
} else {
exec11();
}
или так:
if (condition) {
/**
* функция 1
* @return ...
**/
exec1();
/**
* функция 2
* @return ...
**/
exec2();
/**
* функция 3
* @return ...
**/
exec3();
} else {
/**
* функция 11
* @return ...
**/
exec11();
}
или так:
condition ? (exec1(), exec2(), exec3()) : exec11();Речь ведь не об этом! А теперь еще раз прочитаем название статьи.
Спасибо за внимание.
Т.е. вы считаете, что не стоит складывать все аспекты программирования воедино,
стоит уделять внимание лишь одному из, как то:
- пишу понятно, ну и что, что страдает быстродействие.
- мне важен размер кода, наплевать на наглядность и масштабируемость.
Никто не спорит, что так делать дозволяется, но получается ненаглядно и стиль неверный.
стоит уделять внимание лишь одному из, как то:
- пишу понятно, ну и что, что страдает быстродействие.
- мне важен размер кода, наплевать на наглядность и масштабируемость.
Никто не спорит, что так делать дозволяется, но получается ненаглядно и стиль неверный.
Котлеты отдельно, а мухи - отдельно. Eval тоже называют Evil-ом и не рекомендуют, но используют повсеместно. А почему, а потому, что везде нужна голова в правильном месте.
Не надо, пожалуйста, про наглядность, неверный стиль и и т.д. нет эталона программиста, по которому можно судить об этих вещах. Вам не наглядно, мне наглядно, а Вася Пупкин и -if- в первый раз видит... Петя кричит «стиль верный!», Александр — «нет, он неверный!».
Именно поэтому слов быстро, наглядно, стильно вы не найдете в этой статье.
Не надо, пожалуйста, про наглядность, неверный стиль и и т.д. нет эталона программиста, по которому можно судить об этих вещах. Вам не наглядно, мне наглядно, а Вася Пупкин и -if- в первый раз видит... Петя кричит «стиль верный!», Александр — «нет, он неверный!».
Именно поэтому слов быстро, наглядно, стильно вы не найдете в этой статье.
Кроме названия статьи приходится читать ещё и саму статью. ;) А там речь не про "просто дополнительный способ использования", а про замену if (не if-else, что ещё куда ни шло, а именно if), про "bitwise" не в тему и т.п. Так что не списывайте всё на многозначительное название, текст говорит сам за себя. А теперь ещё раз прочитаем статью.
Спасибо за внимание.
Спасибо за внимание.
Уважаемый, вы начинаете уже напрягать. Читайте по слогам: я замену if-else не предлагаю. Идет речь о расширении функциональности именно тернарного оператора. Забудьте про if! Не было его. Я даже специально удалю упоминание if конструкции из текста.
тернарный оператор изначально замена if-else и применять его можно по-разному, как и while вместо for, case вместо if и т.д. А «в тему» или «не в тему» пусть выбирают читатели и судя по оценке они согласны с вами. Давайте на этом и остановимся.
Этой мертво_статьей я хотел открыть новый блог «JavaScript», в котором обсуждать все связанное с этим языком. Блог открыт, статья не удалась, но я надеюсь увидеть Вас и участвующих в комментариях в качестве активных участников блога, которые поделяться более полезными наработками и открытиями.
Да нормальная статья. Я думаю, лучше писать вещи, порождающие споры, чем не вызывающие никакой реакции ;)
А вы попробуйте ;) Я увы никогда не пойму людей, говорящих, что писать — это не труд (пусть даже никто не согласится, но человек потратил время чтобы поделится... не copy-paste, а обдумал, написал, оформил), при том не написавших ни одной статьи, не поделившихся ничем, кроме яда.
Откуда им знать что лучше, если они не пробовали? :)
Когда практически каждая публикация превращается в битву инакомыслящих с автором ради галочки «я тут отметился»(зеленой галочки ;)). Ведь если человек не согласен, не пользуется, не нуждается, он может просто интеллигентно пройти мимо. Надавить на стрелочку показывающую вниз и уйти читать что-нибудь еще, но нет обязательно нужно что-то едкое написать, заклеймить, навязать свое видение.
Тьфу, извините.
Откуда им знать что лучше, если они не пробовали? :)
Когда практически каждая публикация превращается в битву инакомыслящих с автором ради галочки «я тут отметился»(зеленой галочки ;)). Ведь если человек не согласен, не пользуется, не нуждается, он может просто интеллигентно пройти мимо. Надавить на стрелочку показывающую вниз и уйти читать что-нибудь еще, но нет обязательно нужно что-то едкое написать, заклеймить, навязать свое видение.
Тьфу, извините.
Намёк уловил. Ну, так если появилась местами безграмотная статья по мотивам местами безграмотной статьи, как тут мимо пройдёшь. Обязательно нужно что-то об этом сказать. Считайте, что миссия такая - навязывать своё ядовитое мнение, не стоит на это так обижаться, заведомо обвиняя кого-то там в неспособности к хабра-труду, комментируя вашу статью, некоторые уже перекрыли её, как в байтах, так и в пользе да здравом смысле...
Блогу javascript доброго здоровья! ;)
Блогу javascript доброго здоровья! ;)
Максимальный разумный вариант, будь то js, php, java и т.д.
(condition) ? foo() : bar()
Если получается слишком длинным, а на место foo() или bar() хочется засунуть более сложную логику — выделяем эту логику в отдельные функции/методы:
isItPossible() ? doComplexFoo() : doComplexBar()
Будьте счастливы :)
(condition) ? foo() : bar()
Если получается слишком длинным, а на место foo() или bar() хочется засунуть более сложную логику — выделяем эту логику в отдельные функции/методы:
isItPossible() ? doComplexFoo() : doComplexBar()
Будьте счастливы :)
Всё же не удержусь и настоятельно порекомендую:
Мартин Фаулер "Рефакторинг. Улучшение существующего кода" (если погуглить, можно легко найти выложенную в электронном виде, и на русском, и в оригинале).
Мартин Фаулер "Рефакторинг. Улучшение существующего кода" (если погуглить, можно легко найти выложенную в электронном виде, и на русском, и в оригинале).
пушка для воробьев? :)
При таком взгляде на рефакторинг у вас остается только 2 выбора:
регулярно переписывать своё приложение с нуля или
вообще не писать ничего крупнее гостевой книги ;)
регулярно переписывать своё приложение с нуля или
вообще не писать ничего крупнее гостевой книги ;)
тренарный оператор - удобен, но при неумелом многоэтажном награмождении кода очень сильно ухудшает читабельность кода.
ОМГ, да сколько же можно. Неужели так трудно понять, что «читабельность» — это субъективный параметр? Посмотрите на оценку статьи, сделайте выводы сами и не нужно больше маслянных комментариев про масло.
Во-первых, если вы будете относится к своей точке зрения как к единственной, ничего профессионального вы не добьетесь. Не знаю как вы, но я руковожу группой разработчиков, которым приходиться разбираться в таком вот "продвинутом" стиле кодирования. И понятие "читабельность" имеет совсем не субъективное значение, а только сокращает или продлевает срок решения задач. На оценку этой статьи мне лично начхать.
Если вы руководите группой, то должны знать, что есть общепринятые правила группы, т.е. если разработчики решат, что им удобнее выстраивать деревья из тернарных операторов, то это будет их единственный и правильный выбор и им будет начхать на то, что ламер Вася, который только прочитал книжку «Javascript за 24 часа» будет бурчать на счет «нечитабельности» их кода. Теперь возвратимся к нашим баранам: статья не о том КАК НАДО, а о том, что ТАК ТОЖЕ МОЖНО. Предложение, а не утверждение, способ, а не закон.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширенное применение тернарного оператора