Комментарии 117
Сколько лет живу, никак не могу понять, чем пробелы лучше табов.
Код выглядит одинаково в любом редакторе и консоли
А почему это достоинство? Нормальные редакторы позволяют настроить ширину таба под себя. Кому-то комфортнее читать код с широкими отступами, кому-то с узкими.
Табы в этом смысле лучше, но только в том случае, если у всей команды настроено одинаково. Достаточно найтись одному чудику, у которого редактор заменяет табы на пробелы, и вся гибкость ломается.
Вы можете читать/модифицировать в одном редакторе коды разных проектов без перенастройки.
С табами практически невозможно контролировать длину строки. Я поставлю таб на 1 пробел и сделаю 70 отступов.
Нормальные редакторы распознают тип отступа и позволяют настраивать его ширину независимо от того, что на самом деле используется. Другое дело, что не все их используют. Но возможность эта тоже востребована мало, тем более, что просто разная настройка ширины одного и того же отступа иногда превращает код в кашу (например, грепом или диффом в консоли посмотреть), особенно, если вдруг найдётся какой-нибудь любитель горизонтального выравнивания.
Я только недавно наткнулся на эпичные посты, касающиеся обсуждения этой проблемы:
первый: habr.com/company/pvs-studio/blog/118204
и ответ на него: habr.com/post/118208
Если еще не читали, рекомендую. В статьях и комментариях разобрано большое количество причин предпочесть одно другому, и в каких случаях какой способ предпочтительнее
первый: habr.com/company/pvs-studio/blog/118204
и ответ на него: habr.com/post/118208
Если еще не читали, рекомендую. В статьях и комментариях разобрано большое количество причин предпочесть одно другому, и в каких случаях какой способ предпочтительнее
Пробелы легче контролировать в консольной ide, хотя за такое по рукам надо бить за правки на сервере.
Странно, что для перебора массивов предпочтение отдается циклу for...of, а не Array.prototype.forEach, в котором из коробки есть доступ к индексу элемента массива. Еще смущает объявление всех переменных в одном месте. А как же быть с правилом — объявлять переменную поближе к месту использования? Кроме того, не особо удобно рефакторить. В названном «плохим» варианте удаление или закоментирование строки не влияет на другой код. В «хорошем» варианте нужно вырезать из середины объявления, следить за запятыми и точкой с запятой в конце выражения (если удаляется последняя переменная списка). Также не понимаю преимуществ одинарных кавычек. Например в повсеместно используемом формате JSON используются как раз-таки только двойные кавычки. Почему для JS формата дожно быть по другому?
НЛО прилетело и опубликовало эту надпись здесь
Двойные ковычки занимают в два раза больше места.
У вас в редакторе шрифт не моноспейс? Месье знает толк в извращениях.
Пардон, не в тот тред
Согласен насчет того, что без функции работает быстрее. С другой стороны, удобство функции в том, что ее можно создать единожды и передавать в forEach для обработки разных массивов. С for...of придется повторять весь цикл заново для каждого массива.
НЛО прилетело и опубликовало эту надпись здесь
У for...of под капотом вызов метода под ключом Symbol.iterator на старте и вызов метода next полученого итератора на каждой итерации, так что он не дешевле в плане вызовов.
кроме того, если понадобится поддержка старья — понадобятся и полифил для Symbol (по крайней мере с тем, что генерит из for...of babel)
кроме того, если понадобится поддержка старья — понадобятся и полифил для Symbol (по крайней мере с тем, что генерит из for...of babel)
Одинарные кавычки в js (и в css тоже), — чтобы при внедрении в html не нужно было эти кавычки экранировать. В html существует негласное соглашение атрибуты заключать в двойные кавычки (хотя одинарные не запрещены).
Не обязательно.
Слева Firefox60, справа Chrome68
Слева Firefox60, справа Chrome68
для forEach нет break
А return — разве не подходит?
Нет, он не прерывает «цикл».
Есть извращенные способы с try/catch или можно использовать every (но я никогда не пробовал).
Есть извращенные способы с try/catch или можно использовать every (но я никогда не пробовал).
Да я уже вкурил, что лажанул с предположением. Разве что через глобальную переменную, проверяемую в начале функции можно его прервать. По принципу: "if (globalToExit) return;" Но это костыль, а не решение.
forEach в любом случае отработает все элементы итерируемого объекта. Если есть, например, массив из нескольких тысяч элементов и нужно сделать поиск по нему то незачем проходить по остальным элементам если нужный уже найден.
Дык есть же find()
Я привёл поиск только как наиболее понятный пример. Есть огромное количество задач при которых нужно иметь возможность остановить итерирование.
Это понятно. Просто есть стандартный набор паттернов, пришедший из Функционального Программирования, который покрывает практически любые варианты. То есть практически льбой цикл можно превратить в последовательность вызовов этих паттернов. Это будет не всегда самое, быстрое, но почти всегда самое читабельное решение (после небольшой практики — вначале и сам страдал)
Скорее не повторить, а обернуть, ведь капотом декларативных методов старые добрые императивные конструкции. По крайней мере пока доминирующими являются императивные платформы типа intel или arm
согласен, но пока нет «ленивых вычислений» и нормальной оптимизации этих функций в javascript движках старый добрый for остаётся рабочей лошадкой.
Для итерации с остановкой можно использовать every или some. Но, как мне кажется, такое допустимо только в WO-однострочниках.
НЛО прилетело и опубликовало эту надпись здесь
Ничего странного. В Array.prototype.forEach нет возможности использовать break, в то время как в обычных for/while циклах всегда можно. К тому же forEach требует объявления анонимной функции, что не всегда подходит.
PS. Опоздал, кажется тут уже ответили =)
Привычка писать "" вместо '', ни когда не понимал в чём тут подвох. По мне так код с "" выглядит красивее.
У меня осталась привычка от Си. Рационального обоснования ей дать не могу, возможно, от неё действительно стоит избавиться.
НЛО прилетело и опубликовало эту надпись здесь
Насколько мне известное, такое поведение свойственно PHP, а отнюдь не JS.
НЛО прилетело и опубликовало эту надпись здесь
Всякое случается.
Будучи начинающим разработчиком, я в 2008 сильно удивил людей на собеседовании в Яндекс, с апломбом заявив, что return в JS не обязателен, из функции вернется последнее вычисленное значение (перепутал уже даже не помню с чем, с Ruby? CoffeScript тогда еще не было). Даже сумел их убедить и они обещали попробовать. В итоге меня даже взяли.
Молод был, горяч.
С eval, может быть?
Не уверен. Кажется, всё-таки думал про Ruby (он как раз тогда набирал популярность).
Поидее можно плагин для babel сделать, который будет эмулировать такое поведение :)
Хотя это на грани психбольницы конечно ))
Хотя это на грани психбольницы конечно ))
А это даже в стандарте прописано. Только есть маленькая деталь: вычисляемый таким образом результат выполнения блока кода не возвращается из функции :-)
Простите, не понял вас: что же именно прописано в стандарте? Неявного return из функций там не было последний раз когда я смотрел. Я не про оператор ,, если что.
6.2.2. The Completion Record Specification Type
13.2.13 Runtime Semantics: Evaluation
Да, неявного return нету. Я об этом сразу и написал — результат вычисления блока кода обычно никуда не возвращается, особенно из функции...
Да о таком поведении и заканчивающие разработчики не знают. Потому что это неправда.
Когда-то мне объяснили, что в HTML приняты двойные кавычки, и, чтоб писать шаблоны внутри JS удобно использовать одинарные. Действительно было удобно с Ангуларом. В Реакте все равно, но уже привык.
НЛО прилетело и опубликовало эту надпись здесь
Потому что как только вы добавляете в объект новый ключ, вам надо заново форматировать весь объект, если ключ длиннее предыдущих.
Горизонтальное выравнивание — чем оно им не угодило? ИМХО, с ним код выглядит куда красивее, как-то структурнее что-ли.
Полностью согласен. Горизонтальное выравнивание приводит код к псевдо-табличному виду и сразу становится видна структура повторяющихся паттернов кода, а вместе с ней и все технические ошибки (вроде пропущенных скобок, неправильных значений и т. п.).
Кроме этого, такое форматирование упаковывает многостраничные простыни в компактные «таблицы». Я этим подходом пользуюсь постоянно и не счесть, от скольких ошибок и головновной боли он меня избавил.
А переформатитирование кода при изменении — это очень небольшая цена за те преимущества, которые даёт этот подход.
НЛО прилетело и опубликовало эту надпись здесь
Если использовать шаблонные строки с переносом, то происходит либо пичалька с индентацией, либо пичалька с лишними пробелами/табами внутри строк.
НЛО прилетело и опубликовало эту надпись здесь
Внутрь HTML выводили?
НЛО прилетело и опубликовало эту надпись здесь
Ну так браузеры при парсинге или рендерниге (не помню точно) HTML "схлопывают" по умолчанию все пробельные символы в один. Выведите в <pre> или просто console.log
При рендере, конечно же. Если бы это делалось при парсинге — то свойство CSS white-space не могло бы работать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Первый абзац публикации звучит так, будто Google JavaScript Style Guide — это что-то новое. Но он существует с 2010-го года.
НЛО прилетело и опубликовало эту надпись здесь
Считается, что если все промежуточные результаты вычислений сохранять в отдельные переменные, от этого охренительно провышается читаемость. А от выражения с более чем одним арифметическим действием у программиста может случиться инсульт.
Промежуточные переменные нужны для самодокуменирования кода, чтобы потом коллегам не приходилось взламывать ваш однострочник.
Почему не x * (x + 1)?
В примерах кода на StackOverflow и других площадках мне до сих пор попадается var. Не знаю, есть ли у этих людей аргументы в пользу такого выбора
В консоли let писать очень неудобно, потому что если захочешь чуть подправить код и запустить снова — браузер скажет, что такая переменная уже есть. Приходится жать F5.
Поэтому именно для примеров на SO, которые конечно же захочется быстро проверить-посмотреть, писать var представляется оправданным.
Скажу честно: мне стрелочные функции нравятся просто потому, что они смотрятся лучше и аккуратнее. Но, как выясняется, они еще и служат довольно важной цели.… только я вам о ней не расскажу, потому что у вас доку́ментов нету.
Про const и let я вообще не знал, но я стараюсь писать на Javascript как можно реже.
И вроде есть привычки, которые переношу всюду, где есть власть, но по сути переключить свой стиль под линтер — 0 проблем.
Имхо ни один из примеров не только почти никак не влияет на работу и даже читаемость, но и легко исправляется в процессе CI
Сделайте const вариантом по умолчанию, кроме те случаев, когда переменной нужно присвоить новое значение.
А есть случаи когда переменной ну никак, никак нельзя, в коде, присвоить новое значение?
Если у вас есть
const PI = 3.14;
То означает ли это что ваша программа (модуль, функция) грохнется, если изменить это значение на
PI = 3.14159265359;
Когда вы, как программист, пишите или видите в коде const — что вы должны почувствовать из-за этого?
- что где-то дальше в коде значение этой переменной нельзя менять вообще?
- что где-то дальше в коде значение этой переменной менять вообще-то можно, но программист решил этого просто не делать?
- что значение этой переменной строго задано на веки вечные и программист не гарантирует что при ином значении программа вообще будет правильно выполняться?
То есть, когда я вижу в коде const — но мне нужно поменять значение этой переменной, то должен ли я впадать в ступор от размышления — чем это чревато и чем руководствовался вообще тот программист кто вставил это const в этот код? — Не пометил ли он просто все переменные, которые в коде его не меняются, этим const — руководствуясь правилом — метим всё const, а затем уже тем переменным, значение которых меняем при разработке(написании кода), изменяем на let? — Но тогда этот программист страховался от чего?
Напрашивается вывод: const не нужен. (С), достаточно:
let PI = 3.14;
И не заморачиваться правилом: «метим всё const, а затем уже тем переменным, значение которых меняем при разработке(написании кода), изменяем на let.»
P.S. Короче:
— Вы ставите const чтобы указать что при этом значении вы гарантируете работоспособность вашего кода, при ином нет такой гарантии?
— Вы ставите const чтобы указать (кому-то иному или самому себе?) что при написании этого кода вы дальше не меняли величины этих переменных, но если кому надо (при рефакторинге) их поменять, то пусть ставит тогда и только тогда let взамен const?
— Вы ставите const чтобы указать компилятору что-то такое чего он сам знать не может или ему это узнать трудно, но он (компилятор) мог бы типа это знание применить у себя для оптимизации выполнения вашего кода?
— Вы ставите const потому что Google посоветовал вам ставить const? Он большой, ему видней?
Какой обильный и несуразный поток сознания.
Второй и третий варианты вместе.
ВторойЯ видел код в Java, где все такие переменные какой-то э--э-э чудак пометил как final — Не надо так делать, — сказали ему все остальные в команде. И он… перестал.
и третий варианты вместе.В Java, обычно(!), ставят final там и только там, где этого хочет компилятор (IDE подскажет эти места).
V8 (движок JavaScript) никак не учитывает const в коде. То есть он не нуждается в том чтобы узнавать (для оптимизации) от программиста что же программист пометил как неизменяемая величина. Он (V8) может это определить и сам, если он в этом будет нуждаться.
> Я видел код в Java, где все такие переменные какой-то э--э-э чудак пометил как final — Не надо так делать, — сказали ему все остальные в команде. И он… перестал.
Соглашения, не более. Есть плюсы, есть и минусы у проставления минимально, максимально или средних возможных модификаторов доступа по умолчанию. Лично я предпочитаю минимальные. Выражаясь вашими словами, я гарантирую работу при этих модификаторах, а когда их кто-то меняет, то уже он должен будет гарантировать.
> V8 (движок JavaScript) никак не учитывает const в коде. То есть он не нуждается в том чтобы узнавать (для оптимизации) от программиста что же программист пометил как неизменяемая величина. Он (V8) может это определить и сам, если он в этом будет нуждаться.
Сейчас не учитывать — потом может учитывать, например в ситуациях когда «compile time» значение присваивается. Или не применять свои эвристики, а поверить программисту. И V8 не единственный движок. А ещё и вообще закрытые могут быть (есть?) и там мы не можем сказать однозначно учитывает или нет.
Соглашения, не более. Есть плюсы, есть и минусы у проставления минимально, максимально или средних возможных модификаторов доступа по умолчанию. Лично я предпочитаю минимальные. Выражаясь вашими словами, я гарантирую работу при этих модификаторах, а когда их кто-то меняет, то уже он должен будет гарантировать.
> V8 (движок JavaScript) никак не учитывает const в коде. То есть он не нуждается в том чтобы узнавать (для оптимизации) от программиста что же программист пометил как неизменяемая величина. Он (V8) может это определить и сам, если он в этом будет нуждаться.
Сейчас не учитывать — потом может учитывать, например в ситуациях когда «compile time» значение присваивается. Или не применять свои эвристики, а поверить программисту. И V8 не единственный движок. А ещё и вообще закрытые могут быть (есть?) и там мы не можем сказать однозначно учитывает или нет.
VolCh
Никому и в голову не придёт писать типа:
То есть в мире Java совет: "метим всё final, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), выкидываем final." — Никогда не прокатывал вовсе! Причина?
Возможно из-за того, что мир Java итак многословен, что ещё писать final при объявлении переменной? — ну уж, нет!
В мире JavaScript, волей неволей, что-то ведь надо написать что-то справа — let или const — так почему бы не const? — Но что и кому сообщает программист, используя и let и const в своём коде?
VolCh
В мире Java с каждой новой версией всё меньше случаев когда компилятору нужно что-то указывать используя "final".
Я из мира Java. Для меня const это типа аналог final. А final в мире Java это редкий гость в коде.
P.S.
VolCh
Это вы пошутили, про то что const в JS является модификатором иммутабельности? — Не надо так шутить. Новички в JavaScript могут не понять что это шутка.
Соглашения, не более. Есть плюсы, есть и минусы у проставления минимально, максимально или средних возможных модификаторов доступа по умолчанию. Лично я предпочитаю минимальные. Выражаясь вашими словами, я гарантирую работу при этих модификаторах, а когда их кто-то меняет, то уже он должен будет гарантировать.Верно. Но откуда такое неприятия final в мире Java?
Никому и в голову не придёт писать типа:
final String someString = "Lala";То есть в мире Java совет: "метим всё final, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), выкидываем final." — Никогда не прокатывал вовсе! Причина?
Возможно из-за того, что мир Java итак многословен, что ещё писать final при объявлении переменной? — ну уж, нет!
В мире JavaScript, волей неволей, что-то ведь надо написать что-то справа — let или const — так почему бы не const? — Но что и кому сообщает программист, используя и let и const в своём коде?
VolCh
Сейчас не учитывать — потом может учитывать, например в ситуациях когда «compile time» значение присваивается. Или не применять свои эвристики, а поверить программисту. И V8 не единственный движок. А ещё и вообще закрытые могут быть (есть?) и там мы не можем сказать однозначно учитывает или нет.Смотрите, если не учитывать то можно оптимизировать и те переменные которые не помечены как const, но значение которых не меняется. Это плюс. — Иначе у нас будет типа «недооптимизация».
В мире Java с каждой новой версией всё меньше случаев когда компилятору нужно что-то указывать используя "final".
Я из мира Java. Для меня const это типа аналог final. А final в мире Java это редкий гость в коде.
P.S.
VolCh
Очень часто не константы, а иммутабельные переменные. Собственно const в JS этим и является модификатором иммутабельности
Это вы пошутили, про то что const в JS является модификатором иммутабельности? — Не надо так шутить. Новички в JavaScript могут не понять что это шутка.
> Возможно из-за того, что мир Java итак многословен, что ещё писать final при объявлении переменной? — ну уж, нет!
Не понял «ну уж нет» — в Java не хотят писать лишнее слово из-за того что и так многословная? Возможно, но в близком по синтаксису PHP довольно много людей считают final хорошей практикой.
> Смотрите, если не учитывать то можно оптимизировать и те переменные которые не помечены как const, но значение которых не меняется. Это плюс. — Иначе у нас будет типа «недооптимизация».
Это на каждую переменную запускать анализ возможности изменения, на помеченные const можно не запускать.
> В мире Java с каждой новой версией всё меньше случаев когда компилятору нужно что-то указывать используя «final».
Анализ на наличие «неявного» final закрплён в стандарте как обязательный проход компилятора? Или просто особенность оптимизаторов конкретной реализации?
> Это вы пошутили, про то что const в JS является модификатором иммутабельности?
Нет. Это так есть по факту — присвоить новое значение переменной, объявленной const вы не можете, у неё будет одно значение всё время жизни, хоть скалярное, хоть ссылочное. Это не иммутабельность?
Не понял «ну уж нет» — в Java не хотят писать лишнее слово из-за того что и так многословная? Возможно, но в близком по синтаксису PHP довольно много людей считают final хорошей практикой.
> Смотрите, если не учитывать то можно оптимизировать и те переменные которые не помечены как const, но значение которых не меняется. Это плюс. — Иначе у нас будет типа «недооптимизация».
Это на каждую переменную запускать анализ возможности изменения, на помеченные const можно не запускать.
> В мире Java с каждой новой версией всё меньше случаев когда компилятору нужно что-то указывать используя «final».
Анализ на наличие «неявного» final закрплён в стандарте как обязательный проход компилятора? Или просто особенность оптимизаторов конкретной реализации?
> Это вы пошутили, про то что const в JS является модификатором иммутабельности?
Нет. Это так есть по факту — присвоить новое значение переменной, объявленной const вы не можете, у неё будет одно значение всё время жизни, хоть скалярное, хоть ссылочное. Это не иммутабельность?
присвоить новое значение переменной, объявленной const вы не можете, у неё будет одно значение всё время жизни, хоть скалярное, хоть ссылочное. Это не иммутабельность?
Нет. Иммутабельность — это как Object.freeze, только глубокий.
Object.freeze — это как иммутабельность значения объектного типа. const — иммутабельность ссылки на значение объектного типа.
Напрямую мы доступа к значениям объектного типа не имеем, только ссылки в переменных, параметрах и т. п. и именно их делает иммутабельными const — мы можем менять значение объектного типа, на которое ссылается переменна, но не можем менять саму ссылку, заменять один объект на другой. Значение переменной у нас иммутабельное, хотя оно и ссылается на мутабельное значение. С `let ref = Object.freeze({})` наоборот, мы можем мутировать значение переменной, она будет ссылаться на другой объект или вообще скаляром будет, но само объеткное значение изменить не сможем. И только если напишем `const ref = Object.freeze({})` то получим иммутабельную ссылку на иммутабельное значение.
Напрямую мы доступа к значениям объектного типа не имеем, только ссылки в переменных, параметрах и т. п. и именно их делает иммутабельными const — мы можем менять значение объектного типа, на которое ссылается переменна, но не можем менять саму ссылку, заменять один объект на другой. Значение переменной у нас иммутабельное, хотя оно и ссылается на мутабельное значение. С `let ref = Object.freeze({})` наоборот, мы можем мутировать значение переменной, она будет ссылаться на другой объект или вообще скаляром будет, но само объеткное значение изменить не сможем. И только если напишем `const ref = Object.freeze({})` то получим иммутабельную ссылку на иммутабельное значение.
VolCh
В мире Java совет: "метим всё final, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), выкидываем final." — Никогда не прокатывал.
VolCh
VolCh
Считать const в JS модификатором иммутабельности — это довольно экзотично и необычно! И лучше не стоит. Ибо для применения иммутабельности в JS есть целые библиотеки!
И не надо смешивать контексты. (С)
P.S.
cons CAPITAL = «Москва»
Тут всё ясно. А теперь — рефакторим:
Пишем вместо этого:
let capital = «Москва»
Код также ясен. Но при рефакторинге этой строки все вышеперечисленные вопросы отпадают и не требуется изучать особенности применения этой переменой.
Вот-вот чём дело то!
Другой пример:
cons PI = 3.14
Тут всё ясно. А теперь — рефакторим:
А если так:
let pi = 3.14
Смотрите, всего лишь отказ от const и нам не надо изучать при рефакторинге этого кода, что же именно хотел нам передать программист при написании этой строки? Что он имел ввиду?
Использование const в коде — это как «финишная полировка лаком» предмета — предмета, который типа уже не будет подвергнут переделки. Но с кодом так не выйдет — обычно код постоянно меняют. (С)
const не нужен в JavaScript (С)
На этой картинке «const» попадает в левую толстую книгу.
Не понял «ну уж нет» — в Java не хотят писать лишнее слово из-за того что и так многословная?Да.
В мире Java совет: "метим всё final, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), выкидываем final." — Никогда не прокатывал.
VolCh
Анализ на наличие «неявного» final закрплён в стандарте как обязательный проход компилятора? Или просто особенность оптимизаторов конкретной реализации?В Java что не релиз то новая версия компилятора.
VolCh
Я бы сказал, что зависит от контекста и бэкграунда понимающего.mayorovp верно вам возразил: "обычно под иммутабельностью понимают глубокую иммутабельность."
Считать const в JS модификатором иммутабельности — это довольно экзотично и необычно! И лучше не стоит. Ибо для применения иммутабельности в JS есть целые библиотеки!
И не надо смешивать контексты. (С)
P.S.
cons CAPITAL = «Москва»
Тут всё ясно. А теперь — рефакторим:
- Можно ли получить значение CAPITAL с сервера? — изучай.
- Можно ли заменить значение «Москва» на «Минск» — изучай.
- Зачем автор вообще именно так написал, что он этим хотел сказать? — загадка или изучай или просто так?
Пишем вместо этого:
let capital = «Москва»
Код также ясен. Но при рефакторинге этой строки все вышеперечисленные вопросы отпадают и не требуется изучать особенности применения этой переменой.
Вот-вот чём дело то!
Другой пример:
cons PI = 3.14
Тут всё ясно. А теперь — рефакторим:
- Можно ли заменить значение на 3.14159265359 строке? — изучай!
- Можно ли получить значение с сервера, задав число после десятичного знака? — нет
- Зачем автор вообще именно так написал, что он этим хотел сказать? — загадка или изучай или просто так?
А если так:
let pi = 3.14
- Можно ли тогда писать?:
pi = service.getPiWithNumberOfDecimals(10) || pi;
Да, пожалуйста.
- Можно ли записать let pi = 3.14159 — да.
- Можно ли записать let pi = 3.14159265359 — да.
Смотрите, всего лишь отказ от const и нам не надо изучать при рефакторинге этого кода, что же именно хотел нам передать программист при написании этой строки? Что он имел ввиду?
Использование const в коде — это как «финишная полировка лаком» предмета — предмета, который типа уже не будет подвергнут переделки. Но с кодом так не выйдет — обычно код постоянно меняют. (С)
const не нужен в JavaScript (С)
На этой картинке «const» попадает в левую толстую книгу.
Поверю, что в мире Java есть свои «у нас так принято», возможно обусловленные ленью, возможно мягкими требованиями, в частности редкости требования использования защитного программирования.
Тупая замена const на let или var не приводит к отпаданию ответов на вопросы. Если просто каким-то стайлгайдом будет запрещено использование const, то изучение кода для ответа на вопросы также, если не в большой степени будет необходимо, посколько разработчик объявляя переменной то, что он считает константой, будет обращаться с ней скорее всего как с константой, то есть не будет делать предположений, что кто-то потом в коде может изменить значение динамически. А может будет как с переменной, но ничто нам это не говорит. А вот использование const явно скажет что поддержку возможности изменения значения нам надо делать самим.
Тупая замена const на let или var не приводит к отпаданию ответов на вопросы. Если просто каким-то стайлгайдом будет запрещено использование const, то изучение кода для ответа на вопросы также, если не в большой степени будет необходимо, посколько разработчик объявляя переменной то, что он считает константой, будет обращаться с ней скорее всего как с константой, то есть не будет делать предположений, что кто-то потом в коде может изменить значение динамически. А может будет как с переменной, но ничто нам это не говорит. А вот использование const явно скажет что поддержку возможности изменения значения нам надо делать самим.
VolCh
VolCh
Указывая const, разработчик указывает что дальше он уж точно не меняет ссылку в данной переменной, а зачем он это сделал? — этого он и сам не знает, — типа так уж вышло (или всё же сделал с умыслом, который предстоит при рефакторинге ещё найти далее в коде).
Конечно, если бы (да кабы), в JavaScript отсутствие любого модификатора было бы эквивалентно поведению как теперь при модификаторе let — то и вопросов бы вовсе не возникало — никто и никогда бы вообще не использовал бы ни одного модификатора (var и т.п.). Но — поезд ушёл. (С)
P.S. О лени — Мне один из разработчиков на JavaScript сообщил, что вначале они повелись и писали const («метим всё const, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), метим let.») — «полируя код». Но со временем перестали, так как при рефакторинге им приходилось возвращаться назад по коду и заменять const на let, и они стали использовать только и только let.
Поверю, что в мире Java есть свои «у нас так принято», возможно обусловленные ленью, возможно мягкими требованиями, в частности редкости требования использования защитного программирования.Мир Java — это мир «сурового энтерпрайза» — но вот final там не прижился в методах вовсе.
VolCh
Тупая замена const на let или var не приводит к отпаданию ответов на вопросы. Если просто каким-то стайлгайдом будет запрещено использование const, то изучение кода для ответа на вопросы также, если не в большой степени будет необходимо, посколько разработчик объявляя переменной то, что он считает константой, будет обращаться с ней скорее всего как с константой, то есть не будет делать предположений, что кто-то потом в коде может изменить значение динамически.Нет, указывая let, разработчик уже указывает что это просто переменная, значение которой можно менять.
Указывая const, разработчик указывает что дальше он уж точно не меняет ссылку в данной переменной, а зачем он это сделал? — этого он и сам не знает, — типа так уж вышло (или всё же сделал с умыслом, который предстоит при рефакторинге ещё найти далее в коде).
Конечно, если бы (да кабы), в JavaScript отсутствие любого модификатора было бы эквивалентно поведению как теперь при модификаторе let — то и вопросов бы вовсе не возникало — никто и никогда бы вообще не использовал бы ни одного модификатора (var и т.п.). Но — поезд ушёл. (С)
P.S. О лени — Мне один из разработчиков на JavaScript сообщил, что вначале они повелись и писали const («метим всё const, а затем уже у тех переменным, значение которых меняем при разработке(написании кода), метим let.») — «полируя код». Но со временем перестали, так как при рефакторинге им приходилось возвращаться назад по коду и заменять const на let, и они стали использовать только и только let.
Нет. Если я фактически задаю константу, но почему-то вынужден использовать let или var, то мой код по умолчанию не будет подразумевать возможности изменения значения. Я не буду делать постоянных проверок в кодде на предмет того, а не изменил ли кто-то значение переменной, которую я задвал как неизменяемое при разработке.
Грубо, если в моём коде написано let pi = 3.14, то это не значит, что любой может его поменять даже на 3.14159 в месте иницализации и ожидать корректной работы (собственно даже для const нет таких гарантий), и уж тем более не значит, что после инициализации можно поменять и ожидать корректной работы. Кто-то будет изучать остальной код так же внимательно, как если бы менял const на let, а кто-то почему решит, что раз я написал let, то он может менять переменную где угодно и как угодно, а я ему гарантирую, что мой код это «съест» без проблем. const увеличивает вероятность того, что другой разработчик серьёзно подойдёт к изучению возможных побочных эффектов если он решит менять значение этой переменной где-то после инициализации.
Грубо, если в моём коде написано let pi = 3.14, то это не значит, что любой может его поменять даже на 3.14159 в месте иницализации и ожидать корректной работы (собственно даже для const нет таких гарантий), и уж тем более не значит, что после инициализации можно поменять и ожидать корректной работы. Кто-то будет изучать остальной код так же внимательно, как если бы менял const на let, а кто-то почему решит, что раз я написал let, то он может менять переменную где угодно и как угодно, а я ему гарантирую, что мой код это «съест» без проблем. const увеличивает вероятность того, что другой разработчик серьёзно подойдёт к изучению возможных побочных эффектов если он решит менять значение этой переменной где-то после инициализации.
VolCh
P.S.
Вангую:
Если верен принцип:
Всё что можно не писать в коде (но код при этом будет работать) — будет опущено при написании кода. ©
— пример, указание типов в JavaScript — то, если можно в функциях не думать о том что использовать? (conts или let) и код будет работать(!) — то большинство будет использовать только let.
Если БЫ (да кабы) при создании JavaScript, не указание вообще ничего при определении переменной вело себя так как в Java (то есть как сейчас указание let в JavaScript), то руководствуясь тем же принципом — никто бы вообще ничего не указывал почти никогда! — Но… поезд ушёл. Эх.
Если я фактически задаю константу, но почему-то вынужден использовать let или var, то мой код по умолчанию не будет подразумевать возможности изменения значения. Я не буду делать постоянных проверок в кодде на предмет того, а не изменил ли кто-то значение переменной, которую я задвал как неизменяемое при разработке.Java программисты не парятся по этому поводу, не используя практически final, определяя нужные им переменные в методах класса.
Грубо, если в моём коде написано let pi = 3.14, то это не значит, что любой может его поменять даже на 3.14159 в месте иницализации и ожидать корректной работы (собственно даже для const нет таких гарантий)Для const нет гарантий, но ясно что программист почему то ограничился этим значением и указал что менять его нельзя! — с этим все согласны, — для let pi = 3.14 сразу ясно, что программист вовсе не ограничился значением «3.14».
P.S.
Вангую:
Если верен принцип:
Всё что можно не писать в коде (но код при этом будет работать) — будет опущено при написании кода. ©
— пример, указание типов в JavaScript — то, если можно в функциях не думать о том что использовать? (conts или let) и код будет работать(!) — то большинство будет использовать только let.
Если БЫ (да кабы) при создании JavaScript, не указание вообще ничего при определении переменной вело себя так как в Java (то есть как сейчас указание let в JavaScript), то руководствуясь тем же принципом — никто бы вообще ничего не указывал почти никогда! — Но… поезд ушёл. Эх.
const появляется сам собой, т.к. с опытом приходит понимание что в программировании большинства задач используются в основном константы, а не переменные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
13 интересных моментов из руководства по стилям для JavaScript от Google