Главная
JavaScript, от которого не тошнит

JavaScript, от которого не тошнит -91

18.11.2017 09:17

SergioShpadi 175 10300 Источник

Здравствуйте, меня зовут Сережа и я JavaScript программист. Когда я вижу плохой код, я расстраиваюсь. А я не люблю расстраиваться. И поэтому я иногда пытаюсь объяснить автору, что собственно я вижу плохого в его коде. И чтобы не повторяться, я решил написать небольшой набор истин, на который я смог бы сслылаться на то, как писать хороший код, и как не писать плохой. И дабы все желающие также могли ознакомиться с материалом я решил оформить это все в виде статьи на Хабрахабре.

Для начала, стоит определиться с тем, что такое хороший код, а что такое плохой код. К счастью, нам не придется углубляться в философские рассуждения о понятии качества. Так можно и с катушек слететь, проведя всю оставшуюся жизнь ухаживая за мотоциклом. А у нас все достаточно банально. Так как большую часть времени любой программист занимается чтением кода и его изменением, то хороший код легко читается, легко понимается и так же легко изменяется. Следовательно, плохой код медленно читается, трудно понимается и очень тяжело изменяется. Поэтому наш код должен быть простым, лаконичным и изящным. Чтобы он получался таким, нужно следовать несложным правилам.

Не сокращай слова

Были времена, когда по земле ходили динозавры, а компьютеры были большими, памяти у них было мало, а автокомплита в редакторах не было. Дабы экономить эту самую память и уберечь свои пальцы от излишних нажатий клавиш, хитрые программоцерапторсы записывали переменные в сокращенном виде. Например, в слове image целых пять букв, а в сокращении img всего-навсего три. На эти два байта разницы они и жили. Времена те давно прошли, история стала легендой, легенда превратилась в миф, динозавры вымерли, но традиция сохранилась и прошла сквозь века. Сейчас никакой причины экономить на буквах не осталось, но в коде очень часто можно встретить нечто вроде img.getSrc(). Казалось бы, невелика беда, мозг же легко расшифровывает это до полноценного image.getSource(). Но если в коде на пять строчек десяток переменных с такими названиями, то скорость парсинга кода нашим мозгом резко падает. И это еще не говоря о том, что эти сокращения более-менее распространены, а что такое cls.setCfc(0.5) незнакомый с кодобазой человек в жизни не догадается.

Не бойлерплейть

Бойлерплейт — это плохо, это все знают. И мы не будем писать бойлерплейт. Верно? Но чтобы этого не делать, надо четко определить, что же этот самый бойлерплейт такое. То, что любые повторения кода, являются бойлерплейтом, это и так понятно. Но что еще?

Работа разработчика — это переносить смыслы из неосязаемого ментального вида в строго структурированную запись на конкретном языке программирования. Поэтому все, что не несет какой-либо смысловой нагрузки и не является структурным элементом, является лишним.

Например, в JavaScript лишними являются точки с запятой. Они не несут смысла, и не имеют структурной роли. Они лишь занимают лишнее место на экране и замедляют чтение кода.

const number = 100
// чище чем
const number = 100;

Когда точек с запятыми на экране много, то они очень сильно мешают восприятию кода. Также в JavaScript в некоторых случаях лишними являются круглые и фигурные скобки.

const addOne = number => number + 1
// чище чем
const addOne = (number) => {  return number + 1 }

Операторы if-else генерируют очень много грязи. Лучше не использовать else вовсе, а с if, если выполняется всего одна строка не писать скобок. Вообще идеально заменять то, что можно на тернарный оператор.

const abs = number => {
  if (number >= 0) return number
  return -number
}
// лучше чем
const abs = number => {
  if (number >= 0) {
     return number
  } else {
      return -number
  }
}
// но в идеале 
const abs = number => 
     number >= 0 ? number : -number

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

Пиши в функциональном стиле

Когда я вижу в коде цикл for, я поперхиваюсь своим смузи. Писать императивно в 2017 году — это моветон. Императивный код по большей части — это просто бойлерплейт. Очень мало ситуаций действительно требуют его применения. В прикладных задачах таких ситуаций почти не бывает.

const numbers = [1,2,3]

// Бойлерплейт
const doubleNumbers = []
for (var i = 0; i < numbers.length; i++) {
  doubleNumbers.push(2 * numbers[i])
}

// Нормальный код
const doubleNumbers = numbers.map(number => number * 2)

Инкапсулируй модули

Хороший JavaScript код разделен на хорошо абстрагированные модули. Чтобы их связность была минимальна, стоит придерживаться нескольких простых правил.

Каждый модуль должен лежать в директории с файлом index.js внутри
Именнованные .js файлы вроде button.js создавать не стоит
Директорий без index.js тоже создавать не стоит
Если нужно иметь несколько модулей в одной директории создайте index.js файл, импортируйте в него все модули

# Плохо
component/
+-- button.js
L-- panel.js

# Тоже плохо
component/
+-- button/
¦   L-- index.js
L-- panel/
    L-- index.js

# Хорошо
component/
+-- button/
¦   L-- index.js
+-- panel/
¦   L-- index.js
L-- index.js

Импортировать вы должны только модули, находящиеся на одном уровне с тем, в который происходит импорт. Импортировать что-либо из детей или родителей не стоит.

// Плохо
import {Button} from '../../component'

// Тоже плохо
import {Button} from './component/button'

// Хорошо
import {Button} from './component'

Чтобы сделать модуль, который можно импортировать откуда угодно, положите его в source/shared и добавьте алиас. Так вы сможете импортировать этот модуль как обычную npm зависимость.

source/
L-- shared/
    L-- component
        +-- button/
        ¦   L-- index.js
        L-- index.js

import {Button} from 'component'

Таким образом создается очень простой и понятный top-down flow, который очень легко рефакторить и изменять. Если же не следовать данным правилам, то код превращается в кашу.

Не комментируй код

Ничего не засоряет код больше, чем комментарии. Если комментарии используются для обозначения типов, то для решения этой задачи гораздо лучше подойдут Flow или PropTypes. Если комментарии поясняют смысл написанного, то видимо стоит отрефакторить этот кусок кода и сделать его более понятным для читателя. JavaScript высокоуровневый язык, на нем можно решать только высокоуровневые задачи. Понятно, зачем нужно объяснять оперирование байтами на Си. Это может быть действительно неочевидно. Но если вам нужно объяснять что делает высокоуровневый код, значит проблема в самом коде.

Располагай равнозначные элементы в алфавитном порядке

Если есть список элементов, чей порядок не имеет никакого значения, то лучше расположить их по алфавиту. К примеру, список импортов лучше сортировать сначала по алфавиту вертикально и горизонтально.

import {ApolloClient, ApolloProvider, createNetworkInterface} from 'react-apollo'
import Application from './application'
import {BrowserRouter} from 'react-router-dom'
import {createStore} from 'react-redux-boil'
import React from 'react'
import ReactDom from 'react-dom'

Вывод

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

Комментарии (175)

Akuma
18.11.2017 12:38
#10527130
+1
После призыва не использовать else дальше даже читать не стал.

Сережа расстраивается не потому что остальные плохие, а потому что Сережа придумал себе собственный стиль кода, который на 99% не совпадает с остальным миром.

По тому, что прочитал:
— Никто и не экономил на «двух байтах» в имени переменной, т.к. в времена такой экономии JS не использовали, а остальное компилировалось и длина имени переменной не имеет смысла. Переменные сокращают для более быстрого ввода и чтения. Просто сокращать надо нормально, cls.setCfc не понятно для нового человека, но если оно используется на протяжении всего кода — то все впорядке.

— Точки с запятой — лишние? Я уже на этом хотел закончить чтение. Точки с запятой позволяют «на глаз» очень быстро определить «границы» и отделить одни выражения от других.

— «Не используйте else». Печатайте левой ногой и не используйте руки — из той же серии.
1. SergioShpadi Автор
  18.11.2017 13:22
  #10527194
  -2
  Каждый программист обладает своим собственным стилем. Не вижу в этом ничего плохого. Вот и решил описать правила моего стиля.
  
  По претензиям:
  1) То есть вы не видете в cls.setCfc ничего плохого, если в коде оно употребляется постоянно?
  2) Да, точки с запятой лишние. Границы блоков определяются не по точкам с запятой, а по отступам и фигурным скобкам. Границы чего выделяют точки с запятой вот тут например:
  
  // Есть точки с запятой const add = (first, second) => { return first + second; }; // Нету точек с запятой const add = (first, second) => { return first + second }
  
  3) В нескольких компаниях, где я работал else считался дурным тоном, так как при использовании небольших чистых функций гораздо лучше сделать return по условию, а дальше return по условию, которое не выполняется. Например:
  
  const exampleFunction = exampleParameter => { if (exampleParameter > 0) return 'a' if (exampleParameter < 0) return 'b' return 'c' }
  1. Akuma
    18.11.2017 13:29
    #10527214
    1) Ничего плохого. Вы же используете переменную i, верно? Почему же не пишите ее как index или temporaryIntegerNumber? Потому что это неудобно.
    
    2) Границы блоков определяются по отступам, например, в Python, но никак не в JS. Возможность писать без точки-с-запятой в JS исключительно опциональная и признана вредной.
    В вашем примере они выделяют границы двух выражений.
    
    3) Тут не «else считается дурным тоном». Это просто читабельное упрощение, согласен. Хотя фигурные скобки я бы рекомендовал всегда использовать, даже если там один return. Позволяет избегать глупых ошибок при появлении второй строчки. Да и просто читабельнее.
    
    В общем, судя по комментариям, статья — не стеб. Прислушайтесь пожалуйста к чужим комментариям, ну правда :)
    
    SergioShpadi Автор
    18.11.2017 14:18
    #10527256
    -1
    1) Я пишу целиком слово index
    2) В приведенных мною примерах точки с запятой ничего не отделяют. Отделают выражения друг от друга переносы строк.
    
    Akuma
    18.11.2017 14:19
    #10527258
    1) Серьезно? Тогда я больше не буду с вами спорить.
    
    ngalayko
    18.11.2017 15:34
    #10527332
    пишите тогда integer — i не от слова index )
    
    myxo
    18.11.2017 15:36
    #10527334
    Вообще i (как и j, k) — от стандартных обозначений единичных векторов в прямоугольных системах координат.
    
    ngalayko
    18.11.2017 15:38
    #10527336
    это из фортрана
    
    argentumbolo
    18.11.2017 20:04
    #10527552
    +2
    Вообще-то это из математики.
    Как:
    Фортран просто ввёл неявный тип INTEGER для букв, которые обычно и используются для индексов.
  1. PaulMaly
    18.11.2017 13:33
    #10527218
    В нескольких компаниях, где я работал else считался дурным тоном, так как при использовании небольших чистых функций гораздо лучше сделать return по условию, а дальше return по условию, которое не выполняется.
    
    В какой-то хреновой компании вы работали видимо. Думаю в хипстерской, потому как всегда плохим тоном считался «multiple return».
    
    Границы чего выделяют точки с запятой вот тут например
    
    Ну так почему бы вам не брать еще более простые примеры и условия? Можно прям в одну строку. В реальных проектах только не всегда так бывает и точки запятой иногда являются наилучшими индикаторами. Опять какие-то хипсторские замашки. Просто для справки, вы на чем-то кроме JS писали когда-нибудь? Потому как замечаю, что такое неприятие точек с запятой именно у тех, кто изначально на JS начинал. Интересно подтверждается ли статистика в вашем случае.
    
    То есть вы не видете в cls.setCfc ничего плохого, если в коде оно употребляется постоянно?
    
    Единственное с чем я согласен почти полностью. Да сокращение семантически сначимых переменных — это плохая идея. Однако есть еще и чисто утилитарные переменные и даже общепринятые сокращения, например:
    
    let buff; // используется только в этом месте и только для временного хранения значения, зачем мне тогда писать buffer ? for (let i=0;.....) {} // i - общепринятое сокращение для индекса массива еще со времен С, не нужно мне писать index вместо i
    
    SergioShpadi Автор
    18.11.2017 14:24
    #10527262
    -1
    Об этом я и пишу в первом блоке, что это все пришло к нам из древних времен, когда на то была определенная причина. А сейчас ее уже нет.
    
    Что будет, если написать так:
    
    let buffer; for (let index=0;index<array.length;index++) { .... }
    
    В чем смысл сокращений во времена гигабайтных оперативок и повсеместного автокомплита.
    Ну напишу я вместо buffer сокращение buff. Что мне делать с сэкономленным временем и пространством на экране?
    
    lieff
    18.11.2017 14:39
    #10527284
    Если это только для вас и так вам удобнее — то ничего. А теперь представте что в книге по физике вместо i, j, k, l для индексов, w для мощности и прочих общепринятых обозначений будут использовать полные имена? Читать человеку это станет сложнее.
    Вот например посмотрите сорсы three.js, открыл первый попавшийся файл — индексы и циклы там есть: https://github.com/mrdoob/three.js/blob/dev/src/core/BufferAttribute.js
    
    SergioShpadi Автор
    18.11.2017 14:42
    #10527290
    Three.js это 3d движок. В этой области применение императивного кода уместно, как нигде.
    
    yogurt1
    18.11.2017 18:09
    #10527478
    +1
    Лисперы поперхнулись скобочками
    
    DexterHD
    18.11.2017 16:57
    #10527428
    +1
    Ну напишу я вместо buffer сокращение buff. Что мне делать с сэкономленным временем и пространством на экране?
    
    Можете его бездарно просрать. А можете сделать что-нибудь полезное. Странный вообще вопрос в современном мире. Многие люди дорожат каждой секундой своего времени. Наверное вы пока еще слишком молоды легкомысленны чтобы рассуждать о времени. Но жизнь такая штука, рано или поздно она вас заставит об этом подумать. Все через это проходят.
    
    В чем смысл сокращений во времена гигабайтных оперативок и повсеместного автокомплита.
    
    Позволю себе немного сарказма:
    
    1969:
    -what're you doing with that 2KB of RAM?
    -sending people to the moon
    
    2017:
    -what're you doing with that 1.5GB of RAM?
    -running Slack
    
    FSA
    18.11.2017 19:25
    #10527524
    Когда цикл занимает всего несколько строк и умещается на экране, то какой смысл делать переменную цикла большой? Достаточно одной буквы, всё и так понятно. А если у вас цикл не помещается на экран… Вы не перемудрили? Может стоит как-то переделать код?
    
    PaulMaly
    18.11.2017 21:38
    #10527606
    Об этом я и пишу в первом блоке, что это все пришло к нам из древних времен, когда на то была определенная причина. А сейчас ее уже нет.
    
    Простите, но что вы несете? Условные сокращения — это вообще нормально как бы для разных профессий.
    
    В этом примере, дело совершенно не в оперативках и автокомплитах. Я же вам написал, что есть семантически значимые переменные, а есть чисто утилитарные, которые используются для рутинных операций. Конкретно в примере с циклом, дело давно уже в читаемости:
    
    const posts = [...]; // семантически важная переменная, обязательно пишется полностью и если это массив, то желательно с 's' на конце. for (let index=0;index<posts.length;index++) { console.log(posts[index].title.heading); } for (let i = 0; i < posts.length; i++) { console.log(posts[i].title.heading); } // Индекс - чисто утилитарная переменная, необходимая лишь для доступа к элементу массива. Так как сокращение общепринятое, читается лучше и быстрее, а сам код не закружен лишними словами, не несущими смысла. Доступ к искомому значению получается короче, что также плюс.
    
    Опять же, код бывает разный. Строки лучше не делать слишком длинными. Бывает так, что семантические переменные требуют более подробного описания, а значит использование утилитарных переменных без сокращений, могут просто сделать ваши выражения плохо читаемыми (создают лишний шум):
    
    const postsFilteredByDatTime = posts.filter(....); // лично я лучше сделаю сематически важную переменную длинее, а утилитарную короче //капец for (let index=0;index<postsFilteredByDatTime.length;index++) { console.log(postsFilteredByDatTime[index].title.heading); } //жить можно for (let i = 0; i < postsFilteredByDatTime.length; i++) { console.log(postsFilteredByDatTime[i].title.heading); }
    
    Ну напишу я вместо buffer сокращение buff. Что мне делать с сэкономленным временем и пространством на экране?
    
    У вас в IDE есть вертикальная черта для ограничения длины строки? Если нет, начните использовать, думаю если выработаете над реальными проетами, понимание к вам придет.
    
    Duster
    21.11.2017 10:33
    #10530860
    В сэкономленное время займитесь изучением… Я не знаю, чего-нибудь безвредного. Столярного дела, например.
    
    1. Точки с запятой… Это токенизация, друг. Да, мозгу тоже нужны токены для быстрого чтения. Почитай пару уроков скорочтения, там достаточно хорошо описано, как мозг парсит текст. Второй аргумент — use strict, разу уж ты аппелируешь тем, что в JS это необязательная конструкция языка.
    
    2. Как и в разговорном/литературном языке, так и в языке программирования есть т.н. устойчивые выражения. Контекстный пример устойчивого выражения: «Пёрнуть в лужу». Или, например, недавно анализировал английскую фразу «blow job». Это выражения, которые имеют единый смысл не зависимо от контекста, но чаще всего не прямой. Так и с сокращениями. В циклах уже десятки лет используется i, который каждый интерпретирует для себя по-разному (integer, index, iterate), но всегда в циклах i означает итерируемый индекс, чаще всего целочисленный. И в подсознании опытного программиста есть СЕС, которая отвечает за безусловное определение этой переменной как итерируемой. Сознание даже не задумывается, что это — это факт. То же самое и с buff, это устойчивое выражение. Пытаться доказать обратное — поднять себя на смех и навесить ярлык «бунтарь мамин».
    
    3. else. Если блоки if и else почти идентичны, и состоят из одной-двух строк, то базару нету, это плохая практика, и даже любой анализатор кода тебе скажет об этом. Но вот полный отказ от альтернативы условию — это нонсенс. Помнится, был презабавнейший спор на одном из форумов — парень утверждал, что сможет совсем отказаться от оператора if, и сделать всё на делегатах (C#). Зачем — так и не смог пояснить…
    
    4. Снова про сокращения, но уже не типичные и не устоявшиеся. Да, частично с тобой соглашусь, совсем уж ужимать все подряд названия не стоит, и если есть возможность — лучше сделать их семантичными. Но чаще всего в проекте и/или компании есть устоявшиеся сокращения. У нас, к примеру, это svcTypeId. Кратко, внутри компании всем понятно что это. Писать вместо этого serviceTypeIdentifier — глупо, и такое название засоряет экран. К тому же, мозгу его сложнее токенизировать, ведь придётся уже вчитываться, «а точно ли это нужная мне переменная?».
    
    therhino
    18.11.2017 20:03
    #10527550
    +100500
    Тоже работал в конторе, где некоторые деятели решили, что else — это плохо, зато 10 return'ов в методе — это читабельнее и лучше
  1. TheDeadOne
    19.11.2017 06:48
    #10527882
    Но проще команде работать и новых людей вводить, когда стиль един. Поэтому появились style guide и стайлеры, автоматически проверяющие следование style guide.
1. StjarnornasFred
  18.11.2017 14:32
  #10527266
  +2
  1) «Не сокращай слова» — совет сомнительный, но не лишённый смысла. Если уже привык, то вполне можно сокращать, привыкаешь и не испытываешь затруднений. Хуже, когда по тексту встречается и полный, и сокращённый вариант — в этом случае действительно неочевидно, что это одно и то же.
  2) «Точки с запятой лишние» — нет не лишние они делают код более читаемым в принципе можно и без них но становится трудно читать удобно когда законченные фразы отделены одна от другой
  3) «Пиши функциональном стиле» — сомнительный совет. Многим удобнее и проще программировать императивно, т. е. задавая чёткий алгоритм и отдавая компьютеру команды. Императивный код более читаем и понятен.
  4) «Не комментируй код» — вредный совет. Без комментариев.
  1. Akuma
    18.11.2017 14:35
    #10527282
    1) Согласен. Я и не призывал к обратному. Просто пример из статьи «cls.setCfc» мне почему-то кажется нормальным, т.к. интуиция подсказывает, что оно используется часто и в контексте программы будет вполне понятно. А вырывать переменные из контекста, так и «index» непонятно что делает.
    
    4) Нет уж, комментируйте :)
  1. Large
    18.11.2017 22:46
    #10527648
    2) Можно, но нельзя
    
    console.log('hi') [1,2].forEach(console.log)
1. myxo
  18.11.2017 15:08
  #10527312
  «Переменные сокращают для более быстрого ввода и чтения.»
  Сокращали в те времена, когда не было нормального умного автодополнения, и именно для ввода, а не для чтения. Сейчас (имхо) нужно всегда писать код как будто его читает новый человек, даже если оно используется на протяжении всего кода (говорю как человек, работающий в legacy, поубивал бы всяких сокращателей =)).
  ps. Ну разумеется за исключением всяких i,j,k, но таких исключений можно по пальцам пересчитать.
1. vasIvas
  18.11.2017 16:39
  #10527406
  я согласен с Вами, но запись вида cls.setCfc, лично мне кажется все-таки не красивым.
1. lolmaus
  19.11.2017 14:28
  #10528172
  Точки с запятой — лишние? Я уже на этом хотел закончить чтение. Точки с запятой позволяют «на глаз» очень быстро определить «границы» и отделить одни выражения от других.
  Для этого есть переносы строк.
  
  Я в собственных проектах давно перешел на StandardJS, и жить стало приятнее.
  
  SergioShpadi, я согласен со многими вашими тезисами, но пытаться плыть против течения на Хабре — это карма-суицид. Все ваши слова будут восприняты как призыв запретить святое. Приберегите бисер.
  1. Spiritschaser
    21.11.2017 01:23
    #10530570
    Если вы пишете только на JS, вы радостно не ставите точки с запятыми. Если вы пишите на C#, C, Lua, PHP и JavaScript, отсутствие точек с запятой и любовь к тернарным операторам ввергает вас в ад.

dom1n1k
18.11.2017 12:43
#10527140
Я сначала хотел поспорить, а потом дочитал до смузи — признавайтесь, автор ведь тонко троллит, да?
1. SergioShpadi Автор
  18.11.2017 13:11
  #10527178
  Шутки про смузи, чтобы текст легче читался. Не понимаю, почему вы думаете, что это троллинг. Все написано на полном серьезе. Все правила дельные на мой взгляд.
  
  А о чем поспорить хотели?
  1. dom1n1k
    18.11.2017 13:25
    #10527200
    Утверждения про запятые, else и функциональный стиль сомнительные (мягко говоря).

Akuma
18.11.2017 12:45
#10527144
Тоже увизел смузи. Да это не может быть правдой, у Сережи нет правил JS, у него есть правила троллинга и очень неплохие.

alexwerser
18.11.2017 13:02
#10527168
Это больше похоже на вредные советы
Точка с запятой не нужна?
Ну да в русском языке точка тоже не нужна, можно писать каждое предложение с новой строки
Комментарии не нужны?
Конечно не нужны, потому что все думают также как и вы
И точно знают зачем из нескольких вариантов реализации вы выбрали именно этот
1. SergioShpadi Автор
  18.11.2017 13:27
  #10527210
  Можете привести для примера небольшой кусок JavaScript-кода, в котором явно будет прослеживаться необходимость такого выражения, как точка с запятой? Чтобы вот прям видно было, что без нее тут никак.
  1. Akuma
    18.11.2017 13:34
    #10527222
    Я могу даже без кода его привести:
    
    МожетепривестидляпримеранебольшойкусокJavaScriptкодавкоторомявнобудетпрослеживатьсянеобходимостьтакоговыражениякакточкасзапятойЧтобывотпрямвиднобылочтобезнеетутникак
    
    Примерно так выглядит JS без точек-с-запятой для среднестатистического программиста.
    Читать вроде бы можно, но не удобно, согласны?
  1. PaulMaly
    18.11.2017 13:45
    #10527228
    +2
    Можете привести для примера небольшой кусок JavaScript-кода, в котором явно будет прослеживаться необходимость такого выражения, как точка с запятой? Чтобы вот прям видно было, что без нее тут никак.
    
    Да, легко:
    
    var foo = 1 [1,2,3].forEach(console.log) // Uncaught TypeError: Cannot read property 'forEach' of undefined
    
    Доиграетесь вы с этим. Многие уже проходили.
    
    Akuma
    18.11.2017 13:56
    #10527240
    Мне уже минус в карму кинули. Вас похоже тоже закидают :)
    
    P.S. Пример рабочий. Вернее не-рабочий.
    
    SergioShpadi Автор
    18.11.2017 13:57
    #10527242
    Согласен. В данном случае точка с запятой действительно необходима. Но пример очень уж синтетический. В продакшен коде неименованные значения почти не встречаются.
    
    vmb
    18.11.2017 14:28
    #10527264
    Я вас уверяю, что приблизительно раз в пару месяцев в issues репозитория Node.js появляются посты с жалобами на ошибку, где причиной именно код без точек с запятой.
    
    saggid
    18.11.2017 17:26
    #10527448
    Но всё-таки, тут верно указали, что точки с запятой также принято не ставить в том числе в JS Standard Style, которому следует масса авторитетнейших организаций, вроде гитхаба, разрабов atom'а, npm, express.js, и так далее.
    
    Думаю, не стоит вообще минусовать человека только за то, что он призывает следовать во многом в целом общепринятым во многих современных кругах стандартам.
    
    Хотя я и сам считаю практически все указанные правила такими, что в некоторых случаях надо их нарушить. Но в основе своей они верные. Я лично тоже не использую точки с запятой в своих проектах, и поверьте, текущий проект у нас не такой уж маленький. JS кода там просто навалом. И никаких проблем, в общем-то, не возникает.
    
    vmb
    18.11.2017 17:38
    #10527460
    +1
    Ну, я не минусую. Я понимаю, что это вопрос стилистических предпочтений. И на описанный стиль найдутся десятки других авторитетных стилей и предпочтений. Node.js сознательно предпочитает точки с запятыми в коде, как и популярный https://github.com/airbnb/javascript
    
    justboris
    19.11.2017 00:15
    #10527722
    гитхаба, разрабов atom'а, npm, express.js, и так далее
    Очень спорный список
    
    Github — не видел исходников гитхаба, где можно почитать про их кодстайл?
    
    Atom — тормозной текстовый редактор, точно не пример для подражания. Кстати, более успешный конкурент VSCode использует кодстайл с точками с запятой
    
    NPM — тоже сомнительно. Есть более производительный Yarn, в котором точки с запятой стоят.
    
    Express — открываю исходники, вижу точки с запятой. Вычеркиваем
    
    Так что я так и не увидел "авторитетнейших" организаций, только каких-то хипстеров. Непонятно, почему к их мнению я должен прислушиваться.
    
    В то же время есть стайлгайд Airbnb, который выглядит авторитетнее. Официального кодстайла от Facebook я не нашел, но есть их eslint config и точки с запятой там присутствуют.
    
    saggid
    19.11.2017 04:10
    #10527856
    Мдэ, ну вы притянули за уши реальность, только бы свою точку зрения доказать. Единственное, с чем можно согласиться — то с тем, что в express.js точки с запятой всё-таки стоят, и всё.
    
    Но сидеть и гасить против NPM или Atom — вы конечно очень уж сильно желаете видеть именно свою точку зрения в качестве истины последней инстанции. NPM — это же, блин, ядро современного яваскрипта, ну и что что в Yarn используют точки с запятой? Yarn лишь надстройка над NPM в любом случае.
    
    У вас просто когнитивное искажение (в этом нет ничего оскорбительного, у всех у нас есть множество когнитивных искажений в мышлении). Советую вам всё-таки отказаться от такого образа мышления и почаще находить в себе достаточно смелости, чтобы признать реальность такой, какой она является, иначе вы таким образом очень много ошибочных выводов в своей жизни можете сделать относительно многих процессов, проходящих в ней.
    
    Возвращаясь к нашей беседе — то можно дальше изучать список проектов, использующих этот стандарт, что я и сделаю сейчас немного.
    
    karma, думаю, все знают, насколько известен этот инструмент для тестирования кода. Опять будете искать более крутую альтернативу, разрабы которой используют точки с запятой?) Откажетесь от использования этого инструмента в своих проектах, ибо не соответствует вашей религии?
    
    electron — то, на чём работает огромное количество современного софта, тот же VS Code, Atom, Discord, ну и так далее, и так далее. Тоже вычеркнем от использования?
    
    vue-cli — код утилиты командной строки для одного из самых известных фронтенд-фреймворков современности.
    
    Ну и так далее. Посмотрите сами этот список непредвзятым взглядом, возможно, сами найдете что-то ещё интересное.
    
    P. S. Причём здесь вообще кстати производительность приложения? Вы упомянули это, написав про Atom и NPM. Производительность разве зависит от стиля написания кода?
    
    P. P. S. И чем вам так ненавистны хипстеры? Между прочим, очень много современных технологий, которые мы все вместе с радостью сегодня используем — пишут именно они. Такое ощущение, что вы их вообще как разработчиков не рассматриваете, или не желаете рассматривать. Это снова в тему вышеупомянутого когнитивного искажения.
    
    PaulMaly
    19.11.2017 11:39
    #10527986
    Мдэ, ну вы притянули за уши реальность, только бы свою точку зрения доказать.
    
    Может это вы так сильно топите за свое отстутсвие точки с запятой, что привели список прям скажем на самый авторитетных вендоров, только чтобы показать что хоть кто-то использует такой стиль?
    
    Ну и что NPM и Atom? Пакетный менеджер и десктопный редактор, WAT? Почему этот софт должен быть примером для веб-разработки?
    
    Чтож вы не сказали что Google и Facebook используют точку с запятой? Тот же Airbnb аж в гайды закатал. Из наших тот же VK, уж тоже боле авторитетный веб-вендор чем npm и atom. Чтож вы про это не говорите? Где-то ниже приводили статистику 25% против 75%. Вот и все дела.
    
    Да, некоторым компаниям нравиться не писать точки с запятой, и? Зачем это вообще упоминать в споре? Что это вообще доказывает?
    
    saggid
    19.11.2017 11:56
    #10528010
    Да, некоторым компаниям нравиться не писать точки с запятой, и? Зачем это вообще упоминать в споре?
    Не просто компаниям, а есть полноценный общий стандарт написания JS кода, которому они следуют.
    
    Что это вообще доказывает?
    То что можно без проблем писать код без точек с запятой и иметь прекрасно работающие инструменты, вот что это доказывает. Значит никто там не умирает от постоянно проявляющихся ошибок из-за отсутствия точек с запятой, вот что это доказывает.
    
    PaulMaly
    19.11.2017 14:40
    #10528180
    +2
    Не просто компаниям, а есть полноценный общий стандарт написания JS кода, которому они следуют.
    
    Послушайте, если в названии стандарта есть слово «Standard» это еще не значит, что это общий стандарт. Так что не надо вводить людей в заблуждение. На заборах тоже много чего пишут. Лично я использую кодинг стайл очень похожий на AirBnB, с некоторыми не значительными изменениями.
    
    Значит никто там не умирает от постоянно проявляющихся ошибок из-за отсутствия точек с запятой, вот что это доказывает.
    
    Так а кто вам вообще сказал, что так писать не возможно? Мои примеры с кодом вызывающим ошибку были ответом на вопрос автора поста.
    Полагаю, что 75% (если верить статистике представленной ниже), которые пишут точки с запятой, вряд ли делают это только потому, что есть кейсы, вызывающие ошибки. Просто для большенства людей приятнее, понятнее, чище и читабильнее использовать их, чем не использовать.
    
    Вы вот говорите, что в них нет смысла, а по-моему есть и очень даже. Но ведь все это дело вкуса и холивары на эту тему возникают лишь потому, что в очередно раз кто-то пишет статью уверяя, что это не так. При этом приводя лишь крайне субъективные доводы, типа:
    
    const number = 100 // чище чем const number = 100;
    
    Нет, не чище. И еще 75% считают также. Так зачем вообще это писать? Я со своей стороны, могу хоть какие-то доводы привести, доказывающие что из-за данного кодинг стайл могут быть проблемы, а вы то какие доводы можете привести? Лишь то, что вам так больше нравиться. Ну сорян, вы одиноки.
    
    Также и кейс с компаниями на самом деле доказывает лишь то, что некоторым людям нравиться писать так и все. Без какого-то намека на объективное обоснование.
    
    justboris
    19.11.2017 15:41
    #10528228
    Конгитивного искажения у меня нет, я стараюсь быть объективным. С одной стороны мы видим кодстайлы крупных компаний, таких как Google или Яндекс, например. Так называемый "standard" используется в основном ноунейм-компаниями и небольшими проектами.
    
    Если выбирать пример для подражания, я предпочту опыт больших компаний, чем проектов от одиночек. Кроме того, я уже приводил статистику использования разных кодстайлов. Самый популярный Airbnb (36%) и лишь затем Standard (25%). Большинство разработчиков за точки с запятой, и я предпочту быть с ними.
    
    Предполагаю, что если бы "standard" бессовестно не именовал себя "стандартом" (которым он никак не является), то его доля была бы еще меньше.
    
    PaulMaly
    19.11.2017 16:08
    #10528266
    Предполагаю, что если бы «standard» бессовестно не именовал себя «стандартом» (которым он никак не является), то его доля была бы еще меньше.
    
    Именно так, уверен, что многих это вводит в заблуждение. Особенно новичков. Вводят небось в гугл «standard coding style js» и вуаля.
    
    Также уверен, что и до конца страницы мало кто долистывает. Стандарт же!
    
    justboris
    19.11.2017 16:14
    #10528276
    Еще кроме Javascript я пишу на других языках. Например на Kotlin, где точки с запятой не ставятся. Там это заложено в дизайне языка и это нормально, никаких граблей. Поэтому я пишу без точек с запятой, там где без них можно, и ставлю в тех языках, где это надо.
    
    В Javascript точки с запятой нужны. Если их не ставить, то будут потенциальные проблемы. В дополнение к известным граблям про
    
    [1,2,3].forEach()
    
    я еще наступал на грабли в es6 коде
    
    // здесь норм let {x, y} = getPoint(); // здесь обязательно нужны скобки ({x, y} = getPoint());
    
    Почему здесь нужны скобки, можно почитать здесь.
    
    PaulMaly
    19.11.2017 16:22
    #10528290
    Я кстати думаю, то es6 с его новыми конструкциями лишь привнесет новые проблемы связанные с не использованием точек с запятой. Может не о всех мы пока знаем, но новые конструкции всегда требуют времени на практическое применение. Так что думаю, мы увидим не мало интересных «WAT?», в том числе в скопе с semicolon.
    
    saggid
    19.11.2017 17:04
    #10528354
    Вот последнее — это единственное, что я могу из всех текущих примеров засчитать за нормальный довод против отсутствия точек с запятой. Хотя опять же, в реальном проекте ещё с таким не столкнулся, но возможно когда-нибудь столкнусь и подумаю об этом ещё раз.
    
    justboris
    20.11.2017 02:02
    #10528838
    Вот еще один пример вам. Новые template-strings из es6 тоже требуют точек с запятыми перед ними:
    
    soSomething() // вот здесь нужна ";" `Hello world`.split('\n')
    
    Потому что вот такой код является единым выражением
    
    const str = format`myString`
    
    +1 WTF который нужно держать в голове, подписываясь на отсутствие точек с запятой в Javascript.
    
    saggid
    20.11.2017 07:45
    #10528928
    Спасибо. У меня только снова тот же вопрос: зачем писать таким образом шаблон какого-то текста в реальном проекте? Можно ли увидеть реальный кейс, где так писать необходимо?
    
    Опять же, я бы вот например засунул всё это дело в переменную. Чтобы понятно было, что это за шаблон вообще. Чтобы код чуть красивее и яснее стал. Почему вам хочется использовать именно анонимный шаблон, в каких случаях это удобнее? Напишите пожалуйста, если можно.
    
    justboris
    20.11.2017 11:29
    #10529188
    Пока не знаю зачем. Но если внезапно понадобится, то хотелось бы просто взять и вставить эту конструкцию, без дополнительных размышлений об ограничениях кода без точек с запятой.
    
    В Javascript и так достаточно WTF-моментов. Зачем дополнительно усложнять себе жизнь челленджем на код без точек с запятой?
    
    saggid
    20.11.2017 11:36
    #10529198
    Всё-таки, согласитесь, что мы тут каждый по-своему правы) Если узнаете — расскажите, мне будет интересно)
    
    SergioShpadi Автор
    20.11.2017 11:53
    #10529214
    В этом главная проблема ваших аргументов. Вы как и другие комментаторы приводите в пример куски абсолютно синтетического ненастоящего кода. В реальных проектах так никто никогда не пишет. Что вы собственно своими словами и подтверждаете.
    
    PaulMaly
    20.11.2017 12:48
    #10529320
    Вы как и другие комментаторы приводите в пример куски абсолютно синтетического ненастоящего кода.
    
    Какая разница синтетический код или нет, если он валидный и не рабочим его делает лишь отсутствие точки с запятой? А значит писать без точки с запятой в 100% языковых конструкций нельзя сейчас и нет никакой уверенности что можно будет в будущем. Сами видите, что с появлением новых языковых конструкций, кейсов становится все больше. Почему вы уверены, что с развитием языка эти кейсы не станут становиться все менее «синтетическими»?
    
    В реальных проектах так никто никогда не пишет.
    
    Очень громко, я бы не стал ручаться за все проекты в мире. У нас например считается нормальным использовать анонимные массивы, если они не нужны нигде, кроме этого места в коде.
    
    Лично я вообще стараюсь переменными не увлекаться, имхо чем их меньше, тем меньше «шума» в коде, поэтому нет никакой необходимости заводить переменную, если ее значение используется локально в одном месте.
    
    justboris
    20.11.2017 12:56
    #10529334
    В реальных проектах так никто никогда не пишет
    Я так пишу :) Вечером погрепаю исходники крупных проектов с таким кодстайлом, поищу примеры там.
    
    PaulMaly
    20.11.2017 13:00
    #10529338
    Это называется — «у меня в команде так никто не пишет, значит проблемы нет» ))))) Где-то в соседней ветке такая мысля уже проскакивала…
    
    justboris
    21.11.2017 00:23
    #10530510
    Погрепал из репозиториев предложенных saggid
    
    NPM:
    
    точка с запятой перед литералом массива: раз, два, три
    
    пустой for-цикл должен заканчиваться ";": раз
    
    Atom
    
    точка с запятой в деструктурировании: раз
    
    Кроме того, у них в проекте нет линтинга на файлы тестов, там кодстайл у каждого файла свой: пример
    
    Karma:
    
    строка начинается с массива раз
    
    Vue-cli
    
    ничего не нашлось, там просто за кодстайлом не следят
    
    Не так уж мало для кода который "никто никогда не пишет".
    
    PaulMaly
    21.11.2017 10:38
    #10530870
    Не, ну вот че вы придираетесь. Сказали же вам — говно-код все это. Вот в команде у уважаемого saggid никто так не пишет, там одни мастера, а все остальные просто говнокодеры и только. sarcasm.off(); )))))
    
    saggid
    21.11.2017 19:09
    #10531592
    Ёмое… Ну вообще, я польщён таким вниманием к своей персоне. Я об этой проблеме уже и думать как-то перестал.
    
    Я вас так сильно задел своей точкой зрения чтоли?
    
    PaulMaly, и ты снова опускаешься до оскорблений в мою сторону. Я тебя ни разу не оскорбил, вроде бы.
    
    Сабж обсуждать уже просто лень, извините. Приятного кода всем)
    
    PaulMaly
    22.11.2017 02:51
    #10532116
    Я вас так сильно задел своей точкой зрения чтоли?
    
    Я как бы сюда не по вашу душу вернулся, а ответил на комментарий justboris. Хотя конечно не вспомнить вас не смог, потому как это был ваш основной довод — «так никто не пишет»))
    
    PaulMaly, и ты снова опускаешься до оскорблений в мою сторону. Я тебя ни разу не оскорбил, вроде бы.
    
    Сорри, если показалось оскорблением. Вроде бы даже написал «уважаемый». А вот почему вы со мной на «ты», я не уловил. Мы вроде на бродершафт не пили пока)))
    
    Ну и совсем не понятно, чем я мог вас оскорбить, если лишь, по сути, процитировал одну из многочисленных ваших фраз:
    
    Ну всё верно, меня не убедит какой-то теоретический академический пример говнокода,
    
    Вот вам не теоретические примеры из не просто реальных, а очень известных проектов. Так, что так пишут, уважаемый, и еще как пишут. А исходя и этого и все мои примеры были вполне себе реальные.
    
    И еще насчет оскорблений, вот вы не просто оскорбили, но и с какого-то перепугу поставили диагноз другому участнику сообщества, всего лишь из-за того, что он обратил внимание на неточности в вашем комментарии:
    
    У вас просто когнитивное искажение (в этом нет ничего оскорбительного, у всех у нас есть множество когнитивных искажений в мышлении). Советую вам всё-таки отказаться от такого образа мышления и почаще находить в себе достаточно смелости, чтобы признать реальность такой, какой она является, иначе вы таким образом очень много ошибочных выводов в своей жизни можете сделать относительно многих процессов, проходящих в ней.
    
    Так что, чья бы корова мычала, а твоя молчала.
    
    saggid
    22.11.2017 06:16
    #10532154
    О Господи… Когнитивное искажение в мышлении — это не психическое отклонение, я даже написал наверху немного про это. Почитай немного об этом, полезная тема.
    
    На «вы» я бы обращался и дальше, но уважение упало к тебе после всех твоих сообщений с намеками и сарказмом.
    
    Эти примеры, кстати, только доказывают что везде ставить точку с запятой вовсе не обязательно. Даже если ты захотел сделать именно анонимный массив — просто поставь точку с запятой перед ним. И в общем-то да, в целом теперь я согласен, значит можно писать и так. Я уже давно просил примеры реального кода, если ты не заметил, но да как ты заметишь что-то верное в моих сообщениях, когда ты сюда приходишь чтобы просто спорить и писать о мычащих коровах. Мир всем вам.
    
    dagen
    22.11.2017 13:19
    #10532660
    -1
    но уважение упало к тебе после всех твоих сообщений с намеками и сарказмом
    Подозреваю, что у этого человека, судя по его активности в этой ветке и одновременно хамству, осталась какая-то психологическая травма из-за его же косяков, связанных с незнанием ASI, либо неудачная попытка переобучить одного из разработчиков. В любом случае общения не заслуживает.
    
    PaulMaly
    22.11.2017 14:11
    #10532822
    -1
    Когнитивное искажение в мышлении — это не психическое отклонение, я даже написал наверху немного про это. Почитай немного об этом, полезная тема.
    
    И что? Я разве где-то писал о психологии? Вы насколько я понимаю не специалист в когнетивной науке, тогда быть может обойдетесь без подобных выпадов? На мой взгяд, одно только это сообщение более хамское, чем то, что я когда-либо писал вам.
    
    На «вы» я бы обращался и дальше, но уважение упало к тебе после всех твоих сообщений с намеками и сарказмом.
    
    Вы не можете меня не уважать или уважать. Мы друг друга не знаем и не знакомы. Другое дело, что «вы» — общепринятая норма общения не знакомых людей. Когда я говорю «вы» я не подразумеваю уважительное отношение, так же как не уважительное. Поэтому можете меня сколько угодно не уважать, но так как мы не знакомы, извольте обращаться на «вы».
    
    . Я уже давно просил примеры реального кода, если ты не заметил, но да как ты заметишь что-то верное в моих сообщениях, когда ты сюда приходишь чтобы просто спорить и писать о мычащих коровах.
    
    Я вам присылал реальный код, просто без отношения к задаче и писал много раз — что это вполне реальный код. Вы меня слушать не хотели и стояли на своем. В примерах выше, вы увидели, что так многие пишут. Рад, что вы признали ошибку.
    
    Эти примеры, кстати, только доказывают что везде ставить точку с запятой вовсе не обязательно. Даже если ты захотел сделать именно анонимный массив — просто поставь точку с запятой перед ним.
    
    Стиль кода, который подразумевает вариативное поведение для казалось бы однотипных конструкций на мой вгляд плохой стиль кода. Думаю время нас рассудит. Успехов в вашем не легком деле.
    
    Подозреваю, что у этого человека, судя по его активности в этой ветке и одновременно хамству, осталась какая-то психологическая травма из-за его же косяков, связанных с незнанием ASI, либо неудачная попытка переобучить одного из разработчиков. В любом случае общения не заслуживает.
    
    Вот это я называю хамский комментарий. Я разве вам писал сообщения, в которых давал оценочное суждение вашей личности? Тогда с какого перепугу вы опускаетесь до этого? Раз уж на то пошло, подозреваю, что у вас не достаточно много опыта (оценочное суждение), чтобы понять данные проблемы и это ваша проблема. Держите вебя в руках.
    
    Я же в свою очередь несколько раз четко описывал свою личную «боль» на эту тему:
    
    4. Большая часть тех, кого я собеседую и кто не пишет точки с запятой — не понимают почему у них возникает ошибка, когда я начинаю гонять из по этим случаям, а значит они будут тратить рабочее время на этот не нужны по сути опыт. (это лично моя боль)
    
    И не надо догадок
    
    saggid
    22.11.2017 06:17
    #10532156
    Del
    
    MNB
    20.11.2017 12:42
    #10529308
    зачем писать таким образом шаблон какого-то текста в реальном проекте?
    
    как минимум pluralize, l12n,…
    
    Можно еще тут посмотреть примеры зачем нужна точка с запятой
    
    saggid
    20.11.2017 13:01
    #10529342
    как минимум pluralize, l12n,…
    Это да, это всё хорошо, но я имел ввиду именно этот кусок кода:
    
    `Hello world`.split('\n')
    
    Вот зачем писать именно такой код? Ведь незачем. Это вообще не код на самом деле, вроде как, это какая-то бессмысленная конструкция.
    
    Насчёт ссылки — спасибо, посмотрим)
    
    Со своей стороны, я могу скинуть ссылки на статью и видеоролик, в которых приводятся обратные доводы на эту тему,
    
    PaulMaly
    20.11.2017 14:55
    #10529548
    и видеоролик,
    
    Смотрел уже давно. Насколько я помню у чувака 2 довода:
    
    Значительно больше мест, где нужно знать как правильно писать точку с запятой, чем мест где без нее не обойтись. Типа проще запомнить.
    
    Он так учит людей, потому что им очень сложно понять как правильно расставлять точки с запятой.
    
    Может я конечно не либеральный, но мне кажется что если человек хочет стать программистом, ему придется что-то учить — это факт. Раньше блин программеры двоичный код разбирали, а теперь все на поток поставлено — хоп-хоп и новый js-программист. Ну не смог он понять, как расставлять точку с запятой, сложно ему, ведь это запоминать надо. А рынку что надо? Ну, чтоб взял он какой-нить React и хуяк-хуяк и в продакшн.
    
    Блин, я помню как было трудно в C++ втыкать, реально не просто. Указатели и ссылки долго путал, память лилась ручьем, а уж шаблоны вообще мозг кровоточить заставляли. И ниче, зато потому когда JS стал смотреть, даже учить не пришлось особо и точки с запятой как-то сами стали ставится в нужные места.
    
    Ну а первый пункт вообще комментировать сложно. Здесь уже доказали, что с развитием языка таких мест становится все больше и многие из них настолько не очевидны с первого раза, что не думаю что проще их запомнить.
    
    Reon
    19.11.2017 11:31
    #10527976
    Oу, оу, оу, полегче! Можете свое мнение по поводу более производительного Yarn подтвердить чем то?
    
    PaulMaly
    18.11.2017 21:26
    #10527592
    +1
    Ну во-первых, вы просто попросили прислать пример, чтобы «прям видно было, что без нее тут никак». Здесь без нее прям никак и вы вынуждены будете ставить точку с запятой либо в конце первой строки, либо в начале второй.
    
    Во-вторых, синтетический пример или нет, это не так важно. Уверяю вас в коде и такое встречается. Однако этот пример доказывает одну простую вещь — не использование точек с запятой в js-коде это скорее вредная опция, чем основа синтаксиса.
    
    Раз есть кейсы (и кстати насколько я помню, этот далеко не едиинственный), которые тупо ломают ваш код при отстутствии точки с запятой, при том что код совершенно валиден и не так уж просто сразу понять, в чем дело, — это автоматически выносит данный коддинг стайл в разряд «bad practice» при том, что написание кода с точкой с запятой, дает вам 100% избавление от подобных кейсов.
    
    Я вам тоже не с пень колоды пишу все это. Постоянно вижу джуниоров (выпад не в вашу сторону), с хипстерскими наклонностями, которые пишут так, а потом тратят время, чтобы понять почему возникают ошибки подобного вида. К сожалению, в основном таких разработчиков приходится переучивать. Поэтому вас очень прошу, не несите вредные советы в массы, вы лишь создаете лишнюю работу таким людям как я.
    
    karapetyansa
    21.11.2017 20:25
    #10531660
    Не лучше ли ставить точку с запятой только там где она нужна, как раз в этих кейсах, а в остальных случаях не ставить. Зачем ставить точки с запятой там где от них никакого толку?
    Форматеры кода типа Prettier в зависимости от код стайла сами проставят везде точку с запятой, либо уберут и поставят в тех местах где она необходима, например в вышеприведенных примерах Prettier сам поставит точку с запятой.
    
    Точка с запятой в код стайле без точек с запятыми на конце стоки несет дополнительную семантическую нагрузку, что может быть удобно.
    
    saggid
    19.11.2017 05:58
    #10527880
    Пример кстати очень легко правится и вообще выглядит очень надуманным:
    
    var foo = 1 var bar = [1,2,3] bar.forEach(console.log)
    
    Так вообще было бы правильнее написать, вместо того чтобы объявлять какой-то анонимный массив прямо сразу в коде, а потом ещё сразу идти по нему. Чего хорошего в таком-то стиле написания кода?
    
    Можно всё-таки ещё какие-нибудь примеры реальных проблем от отсутствия точек с запятой? Я вот тоже уже около четырёх лет пишу JS в таком стиле — не поверите, я до сих пор ни разу не встретил ни одной проблемы, которая бы возникла именно из-за отсутствия точки с запятой где-то в коде.
    
    PaulMaly
    19.11.2017 11:19
    #10527968
    Извините, уважаемый, но если вы ни разу не встречали такой проблемы, это не значит что ее нет. Моя основная мысль очень проста и я прошу вас постараться ее понять — если есть кейсы, при которых валидный, на первый взгляд, код будет ломать приложение лишь из-за того, что нет точки с запятой, то наиболее железобетонным вариантом исключить подобные вещи будет использование точки с запятой. Вторая мысль — если такие кейсы есть, значит подобный коддинг стайл не является наиболее правильным для языка, тем более если не существует кейса, когда поставленная в правильном месте точка с запятой ломает код.
    
    Пример кстати очень легко правится и вообще выглядит очень надуманным
    
    Что значит легко правиться? Почему этот код вообще должен правиться? Он валидный! Да, писать так не стоит, но так писать никто не может запретить и уверен есть ситуации, когда так писать довольно удобно. Например, кому-то может показаться, что создавать переменную для массива из 2-х значений, который больше нигде и никогда не используется — лишь создавать лишний шум в коде, поэтому почему бы не использовать его inline? Вообще странная у вас логики, типа ну и что ломатся валидный код, мы же можем его переписать по-другому, чтобы не ломалось. Нахер? Только чтобы не писать точки с запятой, ну это маразм.
    
    Можно всё-таки ещё какие-нибудь примеры реальных проблем от отсутствия точек с запятой?
    
    Да, без проблем:
    
    function foo(arr) { var defaultArr = [1, 2, 3] (arr || defaultArr).forEach(console.log) } foo() Uncaught TypeError: [1,2,3] is not a function
    
    Тут вам что не нравится? Вы можете объяснить мне, безусловно невежде, в чем сокральный смысл думать о том, правильно ли я написал код без точек с запятой, вместо того, чтобы спокойно и уверенно писать с ними?
    
    saggid
    19.11.2017 11:46
    #10527996
    Моя основная мысль очень проста и я прошу вас постараться ее понять — если есть кейсы, при которых валидный, на первый взгляд, код будет ломать приложение лишь из-за того, что нет точки с запятой, то наиболее железобетонным вариантом исключить подобные вещи будет использование точки с запятой
    Это как предложить не пользоваться ножами только потому, что об них можно порезаться при неумелом использовании, извините.
    
    У вас голова на плечах. Что не так с тем, чтобы пользоваться ею при написании кода? Мне нравится чистый код, в котором нет точек с запятой. На него просто приятнее смотреть, он выглядит эстетичнее. Да, я могу пожертвовать парой странных кейсов, в которых он может работать неправильно, ради общей красоты кода.
    
    Да, без проблем:
    
    function foo(arr) { var defaultArr = [1, 2, 3] (arr || defaultArr).forEach(console.log) }
    
    Ну опять же, зачем так писать в реальном проекте? Не лучше написать вот так?
    
    function foo(arr) { arr = arr || [1, 2, 3] arr.forEach(console.log) }
    
    Или даже вообще вот так:
    
    function foo(arr = [1, 2, 3]) { arr.forEach(console.log) }
    
    Ну вы поняли. Меня снова не убедил ваш пример, извините. Можно ещё что-нибудь интересное? Мне правда интересно. Конечно, у меня есть условия к коду, извините, у меня голова на плечах имеется, и я могу подумать, что можно сделать с этим кодом, и является ли он вообще полезным для использования в реальном проекте. Поэтому, если можно, покажите ещё какие-нибудь реальные кейсы, чтобы это был такой код, который не возникнет желания исправить на более нормальный вид, как это было с двумя предыдущими примерами, и чтобы в нём точно нужны были точки с запятой.
    
    PaulMaly
    19.11.2017 14:58
    #10528186
    Послушайте, ну прям очень слабо. Я даже не уверен, что это стоит комментировать, но попробую.
    
    Это как предложить не пользоваться ножами только потому, что об них можно порезаться при неумелом использовании, извините.
    
    Кто сказал что это нож? Лично по-моему это скорее бага в движке интерпритатора, кому-то под «мариейивановной» показалось, что так будет круто и запилили.
    
    У вас голова на плечах. Что не так с тем, чтобы пользоваться ею при написании кода? Мне нравится чистый код, в котором нет точек с запятой. На него просто приятнее смотреть, он выглядит эстетичнее. Да, я могу пожертвовать парой странных кейсов, в которых он может работать неправильно, ради общей красоты кода.
    
    Ну и что, что вам нравиться? Ну и что, что вы готовы пожертвовать? Все это лишь субъективное мнение, не более того. А мне вот не нравиться и я не готов, чтобы ко мне ходили джуниоры с вопросом «схерали мой массив вдргу стал функцией», а я бы правил им код. И красоты кода без точек с запятой я не вижу, более того он уродский. И?
    
    Ну опять же, зачем так писать в реальном проекте? Не лучше написать вот так?
    
    Что значит зачем? Разработчик решил написать так. Его код не верный? Есть синтаксические ошибки? Есть логические ошибки? И нет, не лучше. Или есть какая-то принципиальная разница между вашим кодом и этим? Ваш код работает оптимальнее? С какого перепугу вы вообще вмешиваетесь со своим чисто субъективным мнением о красоте и правильности кода в чужой код?
    
    Или даже вообще вот так:
    
    Вообще не рабочий код в инвайроменте проекта, бабел не используется. Будем заставлять? Не верно пишут? Так ведь не модно? Какие-то еще притянутые за уши отмазки?
    
    Ну вы поняли. Меня снова не убедил ваш пример, извините.
    
    Честно говоря, единственное что я понял, что вас не убедит никакой пример. Потому что вы всегда сможете его переписать. Только в условие задачи переписывание кода не входило.
    Также как никому не интересна ваша личная оценка правильности кода и подходов. Менять структуру чужого кода, его замысел только, чтобы не ставить точку с запятой — это уже слишком и напоминает манию.
    
    Поэтому, если можно, покажите ещё какие-нибудь реальные кейсы, чтобы это был такой код, который не возникнет желания исправить на более нормальный вид, как это было с двумя предыдущими примерами, и чтобы в нём точно нужны были точки с запятой.
    
    Ну если вы наконец-то соблаговолите объективно объяснить, чем вам не нравиться представленный код, а не просто «так лучше не делать», тогда я может быть и сформулирую для вас ответ. Пока это выглядит так, что вы пытаетесь увернуться от прямых ответов.
    
    Так что мне ничего не остается, как еще раз донести до вас основную мысль — если кодинг стайл даже теоретически может сломать ваш код — это плохой кодинг стайл. Ибо предназначение его не ломать, а выстраивать.
    
    saggid
    19.11.2017 16:32
    #10528302
    Ну и что, что вам нравиться? Ну и что, что вы готовы пожертвовать? Все это лишь субъективное мнение, не более того.
    Ну блин, и зачем вообще мы тогда сидим и пишем всё это друг другу? Давайте останемся все вместе на своих собственных "субъективных мнениях". Или может всё-таки есть смысл в том, что мы друг другу пишем, и в том числе в наших мнениях, возможно даже субъективных? Чем ваше мнение не субъективное, в ту же сторону вопрос. Я как минимум имею право высказаться и защитить ту позицию, которая мне более приятна. Также как и вы. Что вам так не нравится в этом?
    
    Что значит зачем? Разработчик решил написать так. Его код не верный? Есть синтаксические ошибки? Есть логические ошибки? И нет, не лучше. Или есть какая-то принципиальная разница между вашим кодом и этим? Ваш код работает оптимальнее?
    Ну да, есть разница, чего здесь такого удивительного? Если вы человек, а не интерпретатор кода, то будет лучше, если вы будете стремиться написать свой код таким, чтобы другими людьми он читался как можно легче.
    
    Почитайте какие-нибудь известные книги на тему чистого кода. Всё это известно и абсолютно нормально. Не понимаю, о чём здесь спорить, и зачем.
    
    Если можно сделать код красивее — да, я полезу и сделаю это. С моей точки зрения (ну простите уж, что лезу опять со своей "субъективщиной", но я имею на это право, как и вы в общем-то лезете со своей "субъективщиной" ко мне), вы написали мне два примера говнокода, который лучше было бы привести к более читабельному и ясному виду, который, к тому же, будет работать в том числе и без наличия точек с запятой. Знаете, вы как-будто говорите мне сейчас: "случайте, вот я написал вам два примера говнокода, и этот говнокод не запустится без точек в запятой!". Ну блин!)) Ну дык исправь ты этот говнокод, уже даже интерпретатор тебе говорит о том, что этот код как-то немного попахивает. Понимаю, конечно, я сейчас для вас очень субъективен, но это уже ваше дело, простите, что мне сделать, если у меня вот такое мнение об этом коде?
    
    Вообще не рабочий код в инвайроменте проекта, бабел не используется
    Да вообще-то уже давно все основные браузеры поддерживают ES6 на нативной основе. Если говорить конкретно о ES6, то вскоре бейбл вовсе станет не нужен. Время идёт, движки развиваются.
    
    Честно говоря, единственное что я понял, что вас не убедит никакой пример. Потому что вы всегда сможете его переписать. Только в условие задачи переписывание кода не входило.
    Ну всё верно, меня не убедит какой-то теоретический академический пример говнокода, который если засунуть в проект, то работать без точки с запятой работать не будет. Я не теоретик, не учёный, я практик, я пишу реальные проекты. Я стараюсь всегда исправлять весь код на нормальные, лаконичные и ясные конструкции. В том числе приведённые вами два примера я тоже поправил бы в реальном проекте к более ясному виду, и он работал бы без точек с запятой.
    
    Я думаю, мы с вами вряд ли договоримся. Давайте закончим тогда на всём этом, думаю, вы высказали свою точку зрения, а я высказал свою, и это главное. Я со своей стороны хочу разве что ещё раз заметить, что я своё мнение высказать право имею, и не надо меня тыкать какой-то хернёй из разряда "кому нужно ваше субъективное мнение". Ваше мнение для меня точно также является субъективным, но я вас в это не тыкаю. Проявляйте уважение к другим собеседникам. Мир вам.
    
    PaulMaly
    19.11.2017 17:36
    #10528390
    Чем ваше мнение не субъективное, в ту же сторону вопрос. Я как минимум имею право высказаться и защитить ту позицию, которая мне более приятна. Также как и вы. Что вам так не нравится в этом?
    
    Все просто — я отстаиваю свою позицию, на основе более-менее объективных фактов:
    
    Код без точки с запятой может приводить к ошибкам, там где их нет необходимости ожидать
    
    Как следствие, объективно код с точкой с запятой более надежный код
    
    Подавляющее большинство js разработчиков и компаний пишут код с точкой с запятой, так что скорее это общепринятый стандарт
    
    Большая часть тех, кого я собеседую и кто не пишет точки с запятой — не понимают почему у них возникает ошибка, когда я начинаю гонять из по этим случаям, а значит они будут тратить рабочее время на этот не нужны по сути опыт. (это лично моя боль)
    
    Все это факты. Обратите внимания, я не пишу, что «мол а мне так больше нравится» или «код без точки с запятой выглядит чище и понятнее». Я вам не пытаюсь навязать свое мнение на основе лишь, своего мнения.
    
    Вы же повсюду свое мнение суете. Сперва «код чище», потому «они нафиг не нужны», потому «ну так писать не надо». Все это чистой воды субъектив, а я предлагаю говорить конкретно и конструктивно.
    
    Ну да, есть разница, чего здесь такого удивительного? Если вы человек, а не интерпретатор кода, то будет лучше, если вы будете стремиться написать свой код таким, чтобы другими людьми он читался как можно легче.
    
    Ну так вы опишите развернуто, чем мой пример принципиально отличается от вашего, кроме того, что ваш позволяет не писать точку с запятой и вам так удобнее? Если вы объясните объективно, то я вероятно приму вашу точку зрения. Ну там, «так писать не стоит, потому что получается немене производительный код, лучше писать так, вот бренчмарки», или «вот глядите, так получается лучше, потому что у вас экономится место/память/итп». Где все это? Я то хоть пытаюсь: habrahabr.ru/post/342648/#comment_10528208
    
    Почитайте какие-нибудь известные книги на тему чистого кода. Всё это известно и абсолютно нормально. Не понимаю, о чём здесь спорить, и зачем.
    
    А ну то, есть вы как бы намекаете на то, что вы весь такой начитанный книг и поэтому ваше мнение как бы неоспоримо? Тогда быть может, вы мне неразумному все таки опишете досканально, чем ваш код чище? Давайте не будет опускаться до голосновных заявлений, а? Думаю у меня опыта по-больше чем у вас, но при этом я вас не отсылаю учить матчасть.
    
    вы написали мне два примера говнокода, который лучше было бы привести к более читабельному и ясному виду, который, к тому же, будет работать в том числе и без наличия точек с запятой. Знаете, вы как-будто говорите мне сейчас: «случайте, вот я написал вам два примера говнокода, и этот говнокод не запустится без точек в запятой!». Ну блин!)) Ну дык исправь ты этот говнокод, уже даже интерпретатор тебе говорит о том, что этот код как-то немного попахивает.
    
    Ок, ну предположим это говнокод. Мне не жалко, хотя в комменте, который я вам скопировал, я подробно разъяснил, почему считаю, что и такой код имеет право на жизнь.
    
    Но вот скажите мне, пусть это говнокод для вас, как для эстета, но ведь интерпритатор не эстет. Он дейтвует по правилам и не оценивает красоту кода. Визуально, это код также валиден, если принять стиль без точек с запятой. И все же, интерпритатор, он же просто машина и не может вам говорить ничего, кроме реальных ошибок, на что же он тут ругается? Случаем не на то, ли что кто-то забыл написать точку с запятой? А раз тупая, не способная оценить, что это говнокод, машина говорит, что это ошибка, так может это все же ошибка? И говнокод или нет, тут ни причем. А значит валидный код, можно сделать не валидным лишь не написав точку с запятой. Мне кажется это доказывает лучше, чем любые ваши слова, что для JS — это не норма. Это всего навсего ваша хотелка.
    
    Понимаю, конечно, я сейчас для вас очень субъективен, но это уже ваше дело, простите, что мне сделать, если у меня вот такое мнение об этом коде?
    
    Ок, это ваше мнение. Удачи в переписывании кучи кода за джуниорами. Пусть так, но вы признаете, что эта ошибка связана с не использованием точки с запятой? И что не получается писать без точек с запятой во всех валидных, пусть и не эстетических, случаях?
    
    Да вообще-то уже давно все основные браузеры поддерживают ES6 на нативной основе. Если говорить конкретно о ES6, то вскоре бейбл вовсе станет не нужен. Время идёт, движки развиваются.
    
    Ну вообще то, кроме бразуеров есть и другие окружения))))) Вы прям как в детском саде)))) Да, блин у нас вся компания занимается environment-agnostic приложениями))) Мы то конечно бабел используем, но ведь кто-то может и нет. Давайте все же сперва подождем полного пришествия ES6 и смерти тех окружений, на котором его нет. А потом будет считать, что это ванила, ок?
    
    Я не теоретик, не учёный, я практик, я пишу реальные проекты. Я стараюсь всегда исправлять весь код на нормальные, лаконичные и ясные конструкции. В том числе приведённые вами два примера я тоже поправил бы в реальном проекте к более ясному виду, и он работал бы без точек с запятой.
    
    Ого, как громко. Ну то, что вы не учетый и так понятно.
    
    Проявляйте уважение к другим собеседникам. Мир вам.
    
    Уважение — это когда человек не тычет своим «мнением» в лицо собеседнику, а пытается предоставлять какие-то факты. Ваше мнение «свисает» с каждого вашего абзаца. В таком ключе, мы действительно вряд ли договоримся.
    
    saggid
    19.11.2017 18:16
    #10528428
    Все просто — я отстаиваю свою позицию, на основе более-менее объективных фактов.
    Да были приведены "более-менее объективные факты" и с моей стороны тоже. Я веду разработку достаточно объёмного с точки зрения JS кода проекта, и отсутствие точек с запятой совершенно не сказывается на работе. Да, у нас тут, можно сказать, вообще нет джунов, как-то не знаю, сложилось так. Задачи в проекте обычно сложнее типичного "сделай форму для написания комментариев", и когда кто-то из начинающих приходит в проект, то очень быстро он просто отваливается от него.
    
    Это тоже, как вы выражаетесь, — "всё это факты". Факты из моей жизни.
    
    Быть может, тогда сойдёмся на том, что если в ваших проектах трудится большое число джунов и большая текучка — то в таких условиях необходимо иметь стиль кода, в котором будет прописана необходимость ставить точки с запятой? Ну, в такой ситуации я с вами полностью согласен и скорее всего одним из первых бы проголосовал за такой стиль.
    
    У меня-то ничего не болит от отсутствия точек с запятой. А конструкции типа (arr || defaultArr).forEach(console.log) мы просто не используем в своём коде, обычно вместо этого присваивая значение переменной, пример уже был показан, и никаких проблем с этим нет. Может, если бы вы мне реальный пример реального кода из вашего проекта показали бы — я бы вас лучше понял.
    
    Мы то конечно бабел используем, но ведь кто-то может и нет
    Ну кто-то может и нет, об этом теперь тоже надо сидеть и спорить? Перестаньте цепляться за херню всякую, вот причём здесь вообще эта тема с бейбелом? Вам просто хочется переспорить меня, найти что-то, за что можно зацепиться? Как весь это разговор о бейбеле и ваших рассказах о вашей супер-компании, занимающейся environment-agnostic приложениями, вяжется с нашим разговором о точках с запятой?
    
    Ого, как громко. Ну то, что вы не учетый и так понятно.
    Опять оскорбление в мою сторону. Знаете, я главное в этой беседе что понял — это то, что с вами лично я бы не работал в одной компании, я бы её очень скоро покинул. Вы мне сейчас уже начали напоминаеть одного из персонажей из недавней статьи на этом же ресурсе.
    
    Давайте всё-таки заканчивать беседу. Я вас понял, как я уже написал, в общем-то. Если вы крутой и важный разраб — я за вас рад, конечно. За ваши проблемы, которые решаются вместе с точкой с запятой, — я тоже рад. Но у меня другая дорога, на которой немного другие правила, и за себя я тоже рад, вроде как. До свидания.
    
    staticlab
    19.11.2017 19:06
    #10528454
    У меня-то ничего не болит от отсутствия точек с запятой. А конструкции типа (arr || defaultArr).forEach(console.log) мы просто не используем в своём коде, обычно вместо этого присваивая значение переменной, пример уже был показан, и никаких проблем с этим нет.
    Я правильно вас понял, что любую конструкцию JS, которая начинается с ( или [ следует сразу же считать говнокодом, требующим рефакторинга?
    
    saggid
    19.11.2017 19:20
    #10528462
    Я конечно не говорю за все 100% вариантов, ибо где-то в каком-то конкретном кейсе я бы, возможно, просто забил на своё нежелание ставить точки с запятой и поставил бы её таки конкретно в этом месте, чтобы получить желаемый результат.
    
    Но в целом, я вот смотрю сейчас на весь свой проект текущий, над которым мы работаем уже третий год (и всё это время он активно развивался) — и я не помню ни одного такого места в коде, где бы у нас начиналась строка кода с такой конструкции. Следовательно, видимо, без неё возможно жить. Возможно, она используется заметно реже, чем людям кажется. Также возможно, что я просто привык решать проблемы другими способами. Такая вот у меня позиция на данный момент. Если покажете примеры реального кода, где вы используете такую конструкцию — мне будет интересно посмотреть и подумать, как бы я её написал со своей стороны, также, или по-другому бы немного сделал.
    
    staticlab
    19.11.2017 19:31
    #10528474
    Если покажете примеры реального кода, где вы используете такую конструкцию — мне будет интересно посмотреть и подумать, как бы я её написал со своей стороны, также, или по-другому бы немного сделал.
    Да вам уже приводили примеры, вы начали просто их критиковать. И тут на самом деле проблема в том, что вполне валидная конструкция языка оказывается зависима от предыдущей строки, и за этим нужно самостоятельно следить.
    
    saggid
    19.11.2017 19:35
    #10528476
    Да проблем нет, я могу и последить. Или чуток отрефакторить код. Мы всё также на этом и сидим, в общем)
    
    И почему я не могу покритиковать что-то? Я имею право на это, как человек. Как и вы. Опять же, я про это уже говорил. Вы-то можете приводить примеры, но с чего вы решили, что я обязательно и безоговорочно их приму?) Чего в этом такого плохого, что я могу в своём стиле писать код, и этот код и читаться будет, и работать будет, и точек с запятой содержать не будет при этом? Так почему бы мне не продолжать его писать и дальше, чем я и занимаюсь? Что не так-то? Ну не нравится вам моё мнение и мои решения, есть у вас своё мнение и своя культура — ну я за вас рад. Было бы ещё хорошо, если бы вы за меня тоже порадовались)
    
    PaulMaly
    19.11.2017 19:55
    #10528492
    Да проблем нет, я могу и последить.
    
    Да, вы можете. А кто-то другой нет. Вопрос — зачем? У вас мало что ли задач и проблем, за которыми нужно следить и о которых нужно помнить? Завидую вам тогда.
    
    но с чего вы решили, что я обязательно и безоговорочно их приму?)
    
    Потому что это просто примеры валидного кода. Мы же здесь не говорим об архитектуре приложения, о красоте и эстетике кода, о том как писать надо/не надо, правильно/не правильно. Вы прибежали, и вместо того, чтобы просто смотреть на код с точки зрения интерпритатора JS, вы начали нам рассказывать, что мол это не коддинг стайл виноват, который исключает обязательный в общем-то элемент (';'), а, блин, «код не такой».
    
    Вы может и правы, в том, что код лучше писать не так. И вам видимо повезло, что вокруг вас все пишут «няшно».
    
    Но ведь речь идет не о вас, а о том, что сам интерпритатор JS не позволяет писать 100% валидного кода в вашем стиле, а значит что это плохой стиль, который не покрывает все кейсы языка.
    
    Честно говоря, лучше я вам уже не объясню:
    
    Так что мне ничего не остается, как еще раз донести до вас основную мысль — если кодинг стайл даже теоретически может сломать ваш код — это плохой кодинг стайл. Ибо предназначение его не ломать, а выстраивать.
    
    Это факт просто. Можно ли вам при этом все использовать это коддинг стайл — конечно, используется на здоровье. Мы не против.
    
    Люди курят, пьют и «мариюивановну» жахают и при этом они понимают, что это плохо, но все равно делают. Почему? Потому что им нравится. Вот и у вас тоже самое — вам просто нравится, верно ведь? Только это не повод пристращать всех к этому.
    
    saggid
    19.11.2017 20:02
    #10528496
    Но ведь речь идет не о вас, а о том, что сам интерпритатор JS не позволяет писать 100% валидного кода в вашем стиле, а значит что это плохой стиль, который не покрывает все кейсы языка.
    Ну дык я же не согласен с этим, что и пытаюсь вам донести.
    
    Для меня это совершенно не довод. У всех людей есть голова на плечах. Вы привели пару примеров кода, который не получится выполнить — ну так это в целом не лучшие примеры кода, как я объяснил со своей стороны, и писать код именно так — вовсе не обязательно. Можно написать немного по-другому — заодно код станет чуть более ясным.
    
    Соответственно, для вас это больше академический спор какой-то о возможностях интерпретатора, а для меня — больше практический, связанный с реальными проектами. Можно ли принять моё мнение? Я-то вас прекрасно понял уже давно. Вроде уже всё объяснил. Джунов у нас нет. JS мне интересен как инструмент для решения проблем. Без точек с запятой проблемы решать можно. Многие известные компании с этим согласны, пусть их и не большинство. Можно закрыть на этом беседу? До свидания)
    
    PaulMaly
    19.11.2017 19:46
    #10528484
    Да были приведены «более-менее объективные факты» и с моей стороны тоже.
    Это тоже, как вы выражаетесь, — «всё это факты». Факты из моей жизни.
    
    А теперь, посмотрите пожалуйста опять на список, приведенный мной, и скажите, сколько фактов «из моей жизни» я привел? Ответ — 1. И самое интересное, что вы сами пишете, что просто не встречались с проблемами, описанные в этом факте, по причине, что у вас нет джуниоров. Ну наверное, вам везет пока и можно расслабиться и писать как душе угодно. Но ведь возможно, это только пока.
    
    Ну и насчет «объемности» ваших проектов, а бы немного засомневался, если бы вы не добавили «с точки зрения JS». Сколько у вас там надо кодом то, человек 10 работают? Давайте, вы когда поработаете над проектом, где хотя бы человек 300 работает, у и каждого свой стиль и монастырь, вы мне тогда в личку напишите, как у вас миросознание поменялось, ок?
    
    Перестаньте цепляться за херню всякую, вот причём здесь вообще эта тема с бейбелом? Вам просто хочется переспорить меня, найти что-то, за что можно зацепиться?
    
    Почему это? Я вам предложил код, который не работает, потому что нет точки с запятой, а она обязательна в JS. Вы предложили код, который вообще не работает на многих платформах JS. Я обратил на это внимание, потому как мне намного проще поставить ";" чем писать не рабочий код. Ну а сама ветка разговора вышла в то, что es6 еще далеко не общий стандарт и без бабела реальные проекты пока не работают. Очередной факт с моей стороны.
    
    Так вы можете ответить на простые вопросы:
    
    вы признаете, что эта ошибка связана с не использованием точки с запятой? И что не получается писать без точек с запятой во всех валидных, пусть и не эстетических, случаях?
    
    ???
    
    Знаете, я главное в этой беседе что понял — это то, что с вами лично я бы не работал в одной компании, я бы её очень скоро покинул.
    
    Да, вы правы… оочень маловероятно, но это не точно.
    
    Давайте всё-таки заканчивать беседу.
    
    Беседу начали вы, вам и заканчивать. Тем более, если вы все равно на вопросы не отвечаете.
    
    michael_vostrikov
    19.11.2017 15:26
    #10528204
    Это как предложить не пользоваться ножами только потому, что об них можно порезаться при неумелом использовании, извините.
    Не совсем. Это как предложить не пользоваться обычными ножами, которыми можно порезаться, а использовать вместо них безопасные-супер-ножи, которые никогда не режут то что не надо, но которые на 1 грамм тяжелее.
    
    Вы предлагаете использовать в качестве разделителя пробельный символ, который не имеет своего изображения, а также может использоваться в комментариях или в середине другого оператора.
    
    saggid
    19.11.2017 16:52
    #10528338
    Не совсем. Это как предложить не пользоваться обычными ножами, которыми можно порезаться, а использовать вместо них безопасные-супер-ножи, которые никогда не режут то что не надо, но которые на 1 грамм тяжелее.
    Если стараться привести более конкретный пример далее, можно придумать ещё такой: чтобы подчеркнуть серьёзность намерений вашей организации, вы обязали всех сотрудников в обязательном порядке одевать галстуки. Галстук — это показатель серьёзности. Но есть некоторые организации, в которых люди забивают на эту формальность и не парятся о галстуках, так как в общем-то они считают, что это мелочи, и их работа от их отсутствия хуже не станет. С моей колокольни как-то это сравнение кажется более близким к нашей теме.
    
    Вы предлагаете использовать в качестве разделителя пробельный символ, который не имеет своего изображения, а также может использоваться в комментариях или в середине другого оператора.
    Вообще-то, разделителем является знак перевода на новую строку. Соответственно, визуально вы прекрасно можете увидеть его.
    
    var one = 1 var two = 2
    
    Как видим, здесь у нас написаны две команды. Любой человек визуально сразу это увидит. Даже если здесь нет ни одной точки с запятой. Я же говорю, это как галстуки) Если их нет, то в общем-то, на самом деле, ничего ведь и не меняется.
    
    michael_vostrikov
    19.11.2017 17:50
    #10528402
    Галстук — это показатель серьёзности.
    Но точка с запятой в JS это не показатель серьезности, она не используется для оформления, как например пробел. Это официальный символ для окончания оператора. Если его нет, это не обрабатывается как валидная конструкция, а он добавляется автоматически.
    
    Соответственно, визуально вы прекрасно можете увидеть его.
    Я вижу не его, а следующий оператор, по наличию которого предполагаю, что между ними что-то есть.
    
    Как видим, здесь у нас написаны две команды. Любой человек визуально сразу это увидит.
    Нет. Чтобы проанализировать первую команду, надо сначала взлянуть на вторую, не является ли она продолжением первой.
    Там две, а тут например одна.
    
    var res = a * x*x*x + b * y*y + c * z + d var res = a & b ? ((c + x) * y + z) * 3 : ((d + x) * y - z) * 4
    
    Если ставить точку с запятой, то при чтении первой строки сразу понятно, что оператор еще не закончился. Поэтому меняется. Когнитивная нагрузка.
    
    PaulMaly
    19.11.2017 17:50
    #10528404
    Галстук — это показатель серьёзности. Но есть некоторые организации, в которых люди забивают на эту формальность и не парятся о галстуках, так как в общем-то они считают, что это мелочи, и их работа от их отсутствия хуже не станет.
    
    Вы забыли еще один кейс — использование галстука для еды. И вообще, не обижайте Саакашвили )))))))))))))))))))
    
    Если серьезно, галстук — плохой пример, потому что в данном случае галстук — это как раз стиль без точек с запятой. Потому что, ставя точки с запятой с коде, также как и ходя без галстука, вы случайно не зацепитесь за что-то и не задушите себя. Если же, вы носите галстук или пишете код без точек с запятой — вам слудует быть внимательными, шанс попасть в книгу рекордов Дарвина велик! ))))))))))
    
    Если ставить точку с запятой, то при чтении первой строки сразу понятно, что оператор еще не закончился. Поэтому меняется. Когнитивная нагрузка.
    
    Отличный довод, салютую!
    
    staticlab
    19.11.2017 17:19
    #10528372
    +1
    function foo(arr) { arr = arr || [1, 2, 3] arr.forEach(console.log) }
    
    Так не рекомендуется писать: изменение аргумента функции может отрицательно сказаться на скорости исполнения.
    
    Последний вариант — не совсем корректное преобразование кода, поскольку не будет ловить null.
    
    saggid
    19.11.2017 17:28
    #10528378
    Можно какой-нибудь пруф на первое утверждение?
    
    По второму — это уже придирки же. Вариант (arr || defaultArr).forEach(console.log) тоже не совсем идеален, если рассматривать с этой точки зрения, ибо в эту функцию можно передать true в качестве аргумента, и всё тоже сломается. Я к тому, что не надо засовывать в функцию то, что её потом сломает, либо если это критично — всегда можно написать пару лишних проверок для решения этой проблемы. С точкой с запятой ли, без неё ли — в любом случае, это можно сделать.
    
    staticlab
    19.11.2017 17:33
    #10528382
    https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#3-managing-arguments

BigDflz
18.11.2017 13:02
#10527170
Это статья — пример глупого метода программирования. Если человеку мешает для чтения кода точка с запятой — то это повод для обращения к врачам. Отсутствие комментариев — это уже повод для операции на мозге. Рекомендации с if — ну тут прогер в своём уме? (правда последний вариант несколько смягчает диагноз)… Прошу прощения, что грубо, но такие рекомендации другой реакции вызвать не могут.

denismaster
18.11.2017 13:04
#10527172
+6
JavaScript, от которого не тошнит — TypeScript.

yvm
18.11.2017 13:16
#10527182
+1
Согласен почти со всем, только модули сортировать не буду если этого не умеет делать IDE

PaulMaly
18.11.2017 13:20
#10527188
+1
Ваш код — это пример javascript от которого тошнит. Спасибо, понял как писать не надо.

MNB
18.11.2017 13:23
#10527198
+1
Статья скорее похожа на «Вредные советы» Г. Остера, чем на полноценный стайлгайд.
Или я не заметил среди тегов «irony»?

Finesse
18.11.2017 13:34
#10527220
```
# Хорошо
component/
+-- button/
¦   L-- index.js
+-- panel/
¦   L-- index.js
L-- index.js
```
ИМХО, куча директорий, в каждой из которых по одному файлу — как раз и есть бойлерплэйт. Тем более, что директива для импорта будет написана одинаково как в случае с отдельным файлом, так и в случае с директорией с index.js:
```
import {Button} from 'components/button'
import {Panel} from 'components/panel'
```
Не комментируй код

Если комментарии поясняют смысл написанного, то видимо стоит отрефакторить этот кусок кода и сделать его более понятным для читателя.
Верно для всех языков, даже для того же C. Но комментарии всё же необходимы в некоторых случаев, например:
- Рассказать почему это сделано так, а не что оно делает.
- Дать IDE описание методов, аргументов и т.п. для всплывающих подсказок.
P.S. Все эти стилистические правила — не первостепенные вещи на пути к JavaScript, от которого не тошнит.

KivApple
18.11.2017 13:46
#10527232
+1
Советы насчёт опускания фигурных скобок и предпочтения использовать тернарный оператор ну ОЧЕНЬ спорные. Желаю, что б автору достался код с обилием вложенных тернарных операторов. Если ещё отключить подсветку парных скобок в IDE, то будет вообще шикарно (но даже с этой фичей будет не очень приятно читать код).

Hazrat
18.11.2017 13:54
#10527236
Автор привел стиль кода JavaScript Standard Style, который мне очень нравится
1. justboris
  19.11.2017 00:21
  #10527730
  Этот кодстайл хорош всем, кроме очень спорного пункта про отсутствие точек с запятой. Плохо, что такой непопулярный стиль называется "standard".
  
  Получается странная ситуация, когда якобы "стандартный" стиль на самом деле использует только 25% людей. Источник — результаты из статьи What JavaScript code style is the most popular
  1. Hazrat
    19.11.2017 09:02
    #10527918
    Если смотреть на компании и учреждения, которые пользуются этим стилем, а это GitHub, npm, mongoDB, ATOM, Electron, Украинское правительство и другие, то мне кажется точка с запятой это не такая проблема, иначе они бы его не использовали.
    
    Честно сам выбрал именно этот стиль, из-за отсутствия точки с запятой, ну не буду я писать несколько выражений в одной строке, не хорошо это.
    
    PaulMaly
    19.11.2017 11:30
    #10527974
    Украинское правительство
    
    А ну теперь, уверен, все просто бросятся писать по этому стилю. Все же такой авторитетный вендор. sarcasm.off(); )))))
    
    justboris
    19.11.2017 15:55
    #10528244
    Украинское правительство
    Правительство страны не является IT-компанией, кода там пишется немного и это мнение не может быть авторитетным.
    
    MongoDB
    Открываю код MongoDB драйвера, вижу точки с запятой. Вычеркиваем.
    
    Остаются Gihub и NPM — негусто.
    
    С другой стороны у нас есть компании типа Google или Facebook. Кодстайлам этих компаний я склонен доверять больше.
    
    PaulMaly
    19.11.2017 15:59
    #10528252
    Остаются Gihub
    
    Ну сорцов самого гитхаба я думаю тоже никто не видел. )))) Если только судить по atom/electron, но «это не точно».
    
    justboris
    19.11.2017 16:00
    #10528254
    Atom/Electron разрабатываются гитхабом, о чем написано в копирайтах этих проектов, поэтому считаем их за одну компанию — Github
    
    UPD еще есть немного опен-сорса на Javascript в их организации https://github.com/github?utf8=?&q=&type=&language=javascript
    Там точек с запятой не видно тоже.
    
    PaulMaly
    19.11.2017 16:11
    #10528272
    Atom/Electron разрабатываются гитхабом, о чем написано в копирайтах этих проектов, поэтому считаем их за одну компанию — Github
    
    Да я так и написал, но также написал что «это не точно». Сам гитхаб разрабатывался давно, и нет никакой уверенности в том, что тогда они также как и сейчас верили в необходимость писать без semicolon. Скорее всего его писали другие разработчики, не те что пишут Atom/Electron. Возможно не такие хипстеры. Так что говорить уверенно за сам гитхаб лишь по текущим публичным активностям я бы не стал.
    
    Ну и навряд ли они полезли бы рефакторить весь код гитхаба, лишь бы избавиться от semicolon))) «Но это не точно» ;)

vshemarov
18.11.2017 14:19
#10527260
+1
Уф, дошел до комментов и немного успокоился — мир еще не совсем сошел с ума

Keyten
18.11.2017 15:34
#10527330
Попробуйте CoffeeScript.

KirEv
18.11.2017 15:39
#10527338
а ты в курсе, что в IE javascript требует обозначение окончания строк, и код без ";" в ИЕ тупо выбросит кучу ошибок.

видел не раз перлы без else, с кучей map и конструкциями ..?..:…… голову сломаешь пока разберешься в логике с сотнями ?: и тому подобного…

Вывод

вместо «javascript, от которого не тошнит», охота прокричать «Код, от которого не тошнит», и в догонку «Не тошнит от простого, понятного кода»… Хороший код сразу говорит что он делает, а не ломает голову, потом сознание, потом жизнь ))
1. justboris
  19.11.2017 00:25
  #10527736
  в IE javascript требует обозначение окончания строк, и код без ";" в ИЕ тупо выбросит кучу ошибок.
  Расскажите об этом поподробнее. ASI — часть стандарта языка и поддерживается всеми браузерами. Разрабатываю со времен IE8, никогда не видел связанных с этим проблем.
  1. KirEv
    20.11.2017 12:40
    #10529304
    пример полугодичной давности: наша компания подписала контракт с большим билдингом, около 1к квартир, тест софта оказался отрицательным, как выявилось, ОС проперти менеджера какой-то там windows xp sp2, и в ИЕ синтаксические ошибки… оказалось в одном из .js-файлов отсутствовали `;` в конце строк… это и был весь фикс в 5минут, все заработало. конечно, в наших интересах подсаживать клиентов хром, к примеру, или хотябы просить обновлять вовремя ПО… но все бестолку…
    
    это, блин, какая-то экономия на спичках…
    
    не пойму, чем плохо писать явно и явно определять: вот конец выражения.
    
    justboris
    20.11.2017 12:43
    #10529310
    не хватает контекста. Какой код был вокруг злополучной точки, почему не работал без этого?
    
    Может быть все пофиксилось не от точки запятой, а от того что обновление файла сбросило кеш у пользователей?
    
    KirEv
    20.11.2017 12:54
    #10529332
    для контроля кеша используется древнее: ".js?version=1.2.3"
    
    тупо с того места, где не было в конце выражения `;` код отказывался выполнятся… давняя проблема старые ИЕ, не раз с таким сталкивался. в ИЕ8 изначально такое же было, но с каким-то там обновлением исправилось :)
    
    к сожалению, сейчас не найду среди тысяч коммитов этот фикс и версию ие в котором оно проявилось. у некоторых клиентов в ие вообще jquery не работает… но ничего, посидишь день-другой с тестом версий 3-2-1 и заведешь, или как-то нативно заменишь то что вываливает исключение… иначе для компании минус контракт на несколько тысяч $ потому что клиент с древним ПО не может использовать наш софт. жесть но как есть.
1. Fedcomp
  19.11.2017 00:27
  #10527740
  про IE как то несправедливо. Есть же babel который транспилит в старый код.
1. renskiy
  19.11.2017 09:41
  #10527930
  видел не раз перлы без else, с кучей map и конструкциями ..?..:…… голову сломаешь пока разберешься в логике с сотнями ?: и тому подобного…
  
  А как вам такой перл?
  
  options = options || {}
  
  Голова не заболела? ;)

ngalayko
18.11.2017 15:41
#10527340
пиши все на js так, глядишь его и не поносил бы каждый второй

sbnur
18.11.2017 15:57
#10527356
Интересно — предыдущие три публикации автора прошли на ура — может что-то не так с публикой?
1. dagen
  18.11.2017 17:36
  #10527458
  +1
  В предыдущих публикациях автор не писал про JS :D А сейчас будто бы специально собрал все непопулярные идеи.
  
  Во всём почти не согласен с автором, кроме одного, и, чувствую, меня сейчас тоже заминусуют: соглашусь с автором про semicolon. Нет никакого глубинного смысла использовать точки с запятыми, это просто вопрос традиций в сообществе. Во многих других языках принято не писать их, и эти сообщества себя замечательно чувствуют. Ещё года 4 назад считал, что они обязательны, но сейчас не вижу в них смысла, т.к. правила разделения операторов ES довольно просты.
  
  ua9msn пишет ниже про автора этой статьи:
  
  Точки с запятой нашел — всё, вы нам не подходите.
  Собеседую и проверяю тестовые регулярно около 4 лет и никогда не считал чужой code style минусом. Может и автор тоже так?)
  1. BigDflz
    18.11.2017 18:09
    #10527476
    всё так, или (если быть точнее) не совсем так… я тоже не считаю чужой code style минусом, но только до определённых границ, за которые автор далеко зашёл…
  1. sbnur
    18.11.2017 18:32
    #10527490
    +1
    Да — предыдущие публикации на другие темы. но себя он позиционирует (см. профиль), как JavaScript FullStack developer.
    Вот меня и удивило такое отвержение масс мыслей, высказанных специалистом.
  1. PaulMaly
    18.11.2017 22:00
    #10527614
    Нет никакого глубинного смысла использовать точки с запятыми, это просто вопрос традиций в сообществе. Во многих других языках принято не писать их, и эти сообщества себя замечательно чувствуют. Ещё года 4 назад считал, что они обязательны, но сейчас не вижу в них смысла, т.к. правила разделения операторов ES довольно просты.
    
    Во многих других языках не использование точек с запятой не приводит к ошибкам. ;)
    FYI: habrahabr.ru/post/342648/#comment_10527228
    
    dagen
    18.11.2017 23:43
    #10527704
    Вы привели свой пример аккурат под моей строчкой, где я написал, что считаю эти правила (automatic semicolon insertion) довольно простыми. Давайте не будем по которому кругу проходить холивар, который уже тысячу раз был и на Хабре и на других ресурсах.
    
    P.S. вам что, показать примеры из Go или Python, в которых точка с запятой будет обязательна?
    
    justboris
    19.11.2017 00:31
    #10527744
    Если язык изначально проектировался без точек с запятой, то это нормально.
    
    А в Javascript точки с запятой есть. Возможность их не писать — опциональная, чтобы слепленные на коленке скрипты работали. Дизайн языка предполагает, что в большинстве случаев точки с запятой стоят. Отсюда и проблемы, если следующая строка начинается со скобок.
    
    Развивая тему, в HTML теги закрываются автоматически. Вот это валидный HTML:
    
    <html> <body> <h1>Hello!
    
    Давайте так и писать, красиво же? Да еще и передаваемый траффик меньше будет.
    
    PaulMaly
    19.11.2017 02:52
    #10527818
    Вы привели свой пример аккурат под моей строчкой, где я написал, что считаю эти правила (automatic semicolon insertion) довольно простыми.
    
    Под какой строчкой? В той ветке нет ваших комментариев. В любом случае, какими бы простыми вы лично не считали эти правила, есть еще более простое правило — просто использовать точку с запятой. Это единственная и 100% защита от подобных проблем.
    
    Вообще я стригерил на ваше высказывание о традициях и сравнении с другими языками, где точка с запятой вообще как бы изначально не закладывалась. Имхо, вы это зря и традиции тут ни причем.
    
    P.S. вам что, показать примеры из Go или Python, в которых точка с запятой будет обязательна?
    
    А давайте, только что-то мне подсказывает, что ваши примеры будут значительно более синтетическими чем мой.
    
    dagen
    19.11.2017 13:17
    #10528112
    Я имел ввиду традиции в сообществе. JS Standart известная штука, 15 килозвёзд. Большое количество людей считают это хорошим подходом и активно распространяют этот подход вокруг себя, вокруг них есть какое-то сообщество, где традицией является отсутствие точек с запятыми. Вот вы получите оффер от компании/проекта, где все пишут без точек с запятыми и им это нравится… и вы наплюёте на их code style и будете везде добавлять? Или просто уволитесь/отклоните оффер? :)
    
    Про вашу «100% защиту» вам прекрасно ответил saggid, он выразил моё отношение к этому наверно лучше, чем смог бы я.
    
    А давайте, только что-то мне подсказывает, что ваши примеры будут значительно более синтетическими чем мой.
    Какой показатель выберем для измерения синтетичности?) Или этим показателем будет ваше субъективное мнение? Согласно моему субъективному мнению, все эти примеры синтетические (включая ваш), никто в здравом уме так не будет писать, одновременно «забывая» добавить semicolon. Аналогично я считаю для самого известного из таких примеров (показательно, что это баг в jsmin, а не во вручную написанном коде).
    
    Go: stackoverflow.com/questions/1719999/why-do-i-need-a-semicolon-here
    Python: stackoverflow.com/questions/8236380/why-is-semicolon-allowed-in-this-python-snippet
    
    PaulMaly
    19.11.2017 15:27
    #10528208
    +1
    Ох, уважаемый и вы туда же…
    
    Я имел ввиду традиции в сообществе. JS Standart известная штука, 15 килозвёзд. Большое количество людей считают это хорошим подходом и активно распространяют этот подход вокруг себя, вокруг них есть какое-то сообщество, где традицией является отсутствие точек с запятыми.
    
    Вам тоже напишу — если в стандарте, есть слово «Standard», это не значит, что это стандарт. И вам напишу, что ваше «большое кол-во людей» — это порядка 25%, если верить статистике, приведенной где-то здесь в комментах. А даже если не верить, то есть такая штука как Airbnb JavaScript Style Guide у которой 60+ килозвёзд и что? Если так рассуждать, то вы в любом случае в меньшинстве, а ведь это маргинальное меньшинство всегда есть во всех сферах жизни. А самое интересно, что именно оно самое «крикливое».
    
    Вот вы получите оффер от компании/проекта, где все пишут без точек с запятыми и им это нравится… и вы наплюёте на их code style и будете везде добавлять? Или просто уволитесь/отклоните оффер? :)
    
    Дело в том, что я уже давненько сам раздаю офферы. И да, я редко беру разработчиков, которые не пишут точки с запятой. Хотя конечно бывают исключения и как правило приходится переучивать.
    
    Про вашу «100% защиту» вам прекрасно ответил saggid, он выразил моё отношение к этому наверно лучше, чем смог бы я.
    
    Это прискорбно, что вы так низко себя оцениваете. Ответ уважаемого saggid был крайне слаб и состоял преимущественно из личных субъективных имхо относительно красоты и правильности кода. Не зачет.
    
    Какой показатель выберем для измерения синтетичности?) Или этим показателем будет ваше субъективное мнение?
    
    Ну пока, насколько я понимаю, критерием синтетичности было лишь мнение тех, кто комментировал мой ответ автору. Лично я не вижу синтетичности в том, что какой-то разработчик в вакууме решил не присваивать переменной массив, который используется лишь в одном конкретном месте и нигде более. Давайте посмотрим:
    
    function bar() { var foo = true // как бы принято определять переменные на верху функции ...... // дохрена строк кода foo = false // изменение переменной [1,2,3].forEach(console.log) // массив, не используется нигде кроме этого места, сразу видим что и как. ..... } // или же function bar() { var foo = true var arr = [1,2,3] ...... // дохрена строк кода foo = false // изменение переменной arr.forEach(console.log) // эм, а что это за массив то? погнали смотреть. а зачем ему переменная, если он не меняется, не используется повторно и по-смыслу не должен? ..... }
    
    Я не призываю так писать, но мне кажется, что такой вариант имеет место быть и даже выглядит более наглядно, в определенных обстоятельствах. Или другой пример:
    
    // объясните мне окоянному, чем данный пример хуже function foo(arr) { var defaultArr = [1, 2, 3] (arr || defaultArr).forEach(console.log) } // чем этот? function foo(arr) { arr = arr || [1, 2, 3] arr.forEach(console.log) } // может быть, он более производительный? или в первом примере нарушена логика?
    
    В чем тут вообще синтетика то? Имхо синтетикой являются ответы типа, «ну не, так никто не пишет» или «а зачем так писать?», да блин, затем, что так написано, что так можно писать и что кто-то решил так написать.
    
    Согласно моему субъективному мнению, все эти примеры синтетические (включая ваш), никто в здравом уме так не будет писать, одновременно «забывая» добавить semicolon.
    
    Что значит никто? А если этот никто не знал, что там обязателен semicolon? Почему он вообще должен об этом думать? Зачем ему об этом думать, если он просто может писать и не делать ошибок?
    
    В чем сокральный смысл этого подхода, ВЫ мне можете объяснить? (у многих спрашиваю — никто не отвечает).
    
    Насчет ваших примеров. Отвечу так:
    Go, там же пишут:
    
    Update (March 2012): Newer Go releases are able to compile both forms (with and without the semicolon).
    
    Значит, это была бага. Возможность писать без semicolon также считаю багой JS.
    
    Python: а тут то в чем прикол? На первый вгляд обычный «multiple statements on the single line», так питон же, «basic syntax», епта. Даже в туториалах пишут: www.tutorialspoint.com/python/python_basic_syntax.htm
    
    В любом случае, эти примеры лишь показывают, что в свое время semicolon не зря был добавлен во многие языки и до сих пор есть кейсы, которые требуют таких явных вещей.
    
    dagen
    19.11.2017 18:08
    #10528418
    Вам тоже напишу — если в стандарте, есть слово «Standard» ...
    Не знаю зачем вы придумали, что я считаю, что это стандарт. Более того, я использую как раз Airbnb (без обязательных точек с запятой).
    
    Дело в том, что я уже давненько сам раздаю офферы. И да, я редко беру разработчиков, которые не пишут точки с запятой. Хотя конечно бывают исключения и как правило приходится переучивать.
    Ой не про это был вопрос. `Contributing.md` содержит ссылки на codestyle с отсутствием точек с запятой. Неужели это повод не участвовать в проекте?
    
    Лично я не вижу синтетичности в том…
    
    var arr = [1,2,3] ...... // дохрена строк кода arr.forEach(console.log) // эм, а что это за массив то?
    Хороший показатель «несинтетичности». Слабо себе представляю, как ваши дохрена строк кода (и другие «несинтетические» примеры) могут пройти code review, не говоря уже об автоматической проверке на превышение цикломатической сложности метода. Надеюсь вы не переучиваете разработчиков так писать :)
    
    Почему он вообще должен об этом думать? Зачем ему об этом думать, если он просто может писать и не делать ошибок?
    Плохой подход «не думать», потому как ASI существует независимо от того, думаете вы о нём или нет.
    
    return? ['one', 'two', ... 'twelve'];
    Ваш переученный на точки с запятыми разработчик не влез по ширине строки до линии в редакторе и перенёс массив на следующую строку (вполне в духе «несинтетичности»). И он честно поставил точку с запятой после массива, но это ему не поможет. То же касаемо переноса объявления переменных. Или с объектом, который «для удобочитаемости» размещён на новой строке после `return`.
    
    Сакральный смысл на поверхности и вам его уже говорили, но вы, как практикующий теолог, его отвергаете как ересь. Мне просто так нравится.
    
    Во многих других языках не использование точек с запятой не приводит к ошибкам. ;)
    … // дохрена строчек кода
    так питон же, «basic syntax», епта.
    Хорошая наблюдательность. Так и есть, basic syntax, причём отсутствие точки с запятой вызывает ошибку, что и требовалось доказать. А с Go то же самое, что с JS (да, просмотрел, что приведённый пример плохой), так как там тоже есть автоматическая вставка точек с запятыми.
    
    Засим предлагаю попрощаться, у вас есть чуть выше в ветках куча комментариев, с авторами которых вы можете продолжать практиковаться в теологии.
    
    PaulMaly
    19.11.2017 19:27
    #10528466
    Более того, я использую как раз Airbnb (без обязательных точек с запятой).
    
    Ну, значит вы не используете Airbnb, а лишь свой стандарт на основе его. Ваше право, но это не повод учить плохому других.
    
    `Contributing.md` содержит ссылки на codestyle с отсутствием точек с запятой. Неужели это повод не участвовать в проекте?
    
    Для меня это повод задуматься и возможно засомневаться в том, что проект делают профессионалы. Это мое имхо и право, считать ту же самую точку с запятой — признаком качества кода на JS. Как и многие другие вещи. Из опыта скажу — работать в проекте с плохим коддинг стилем — одни мучения. Поэтому да, скорее всего откажусь.
    Кстати, хотелось бы вам форварднуть такой же вопрос вам: будете писать проект, где точки с запятой — это основа стиля? Или чувство прекрасного не позволит? ))))
    
    Хороший показатель «несинтетичности». Слабо себе представляю, как ваши дохрена строк кода (и другие «несинтетические» примеры) могут пройти code review, не говоря уже об автоматической проверке на превышение цикломатической сложности метода. Надеюсь вы не переучиваете разработчиков так писать :)
    
    Не знаю о какой «дохрена строк» вы подумали. По мне так и 10 строк между этими выражениями уже много, чтобы использовать переменную для подобных вещей. Но вообще говоря в реальных проектах функции бывают длинее чем в туториалах, которые вы видимо читаете. Да, действительно, у нас обычно функции не в одну строку, как в данной статье.
    
    Причем тут код-ревью я уловил только условно, потому как мы разбиваем код на функции не по принципу «чтобы было мало строкоф», а по принципу — делает одну определенну задачу. И уж так повелось, что в разных проектах, задачи бывают разные, в том числе и сложные. Отсюда и функции бывают сложные и очень часто сематически и логически их разбить на несколько не представляется возможным. Про второй пример вам видимо вообще нечего сказать, как и автору «правильного кода»))))
    
    Плохой подход «не думать», потому как ASI существует независимо от того, думаете вы о нём или нет.
    
    А что это приведет к сообщению об ошибке? Вполне себе валидный код и понять почему у тебя функция ничего не возвращает здесь проще простого. А вот понять, почему у тебя массив вдруг интерпритируется как функция — это уже не так просто. Помню как ко мне подбежал чувак с криками, «я сломал ноду», вот примерно из-за такой же ошибки, а мы потом еще какое-то время его троллили. Вы мне сейчас напомнили сказку о репке: тянете-потяните за уши ваши доводы, а вытянуть не можете)))))
    
    Сакральный смысл на поверхности и вам его уже говорили, но вы, как практикующий теолог, его отвергаете как ересь. Мне просто так нравится.
    
    Что и требовалось доказать. Никих объективных доводов ни у вас, ни у других «верующих» нет. А раз так, может не лезть к другим со своим уставом?
    
    Так и есть, basic syntax, причём отсутствие точки с запятой вызывает ошибку, что и требовалось доказать.
    
    Неа, что и требовалось доказать, что даже языки спроектированные без использования точки с запятой, в некоторых кейсах все равно образаются к ней за помощью. Лично имхо, лучше все же выбрать какой-то однозначный вариант — если можете писать всегда и всезде, в 100% валидных кейсах без точки с запятой — пожалуйста, пишите, наверное это круто. А уже ежели не можете (получается и JS и даже Python не могут), тогда уж лучше забыть об этом и ввести точку с запятой как обязательный пункт и избежать тем самым невнятного поведения. И будет всем мир, и stackoverflow будет чист от однотипных вопросов.
    
    А с Go то же самое, что с JS (да, просмотрел, что приведённый пример плохой), так как там тоже есть автоматическая вставка точек с запятыми.
    
    Ок, видимо создатели Go тоже «мариюивановну» любят употребить. Ниче пофиксят когда-нибудь.
    
    Засим предлагаю попрощаться, у вас есть чуть выше в ветках куча комментариев, с авторами которых вы можете продолжать практиковаться в теологии.
    
    Да, можете идти. Посублимировать после нашей беседы ))))
1. michael_vostrikov
  18.11.2017 19:42
  #10527540
  То есть по-вашему у публики не может быть своего мнения, она должна на авторитет автора смотреть и оценивать положительно все что он напишет?
  1. sbnur
    18.11.2017 20:15
    #10527558
    Может — и думаю допустимо удивляться такому единству
    
    michael_vostrikov
    18.11.2017 22:38
    #10527640
    А когда электрики порицают неправильные советы по организации проводки или автолюбители по неправильному уходу за машиной, вы тоже удивляетесь? Наверно с ними тоже что-то не так.

fly_style
18.11.2017 16:47
#10527412
+2
Интересная попытка навязать свой codestyle. Но разработчики вокруг еще не сошли с ума, поэтому я счастливо выдохнул, посмотрев комментарии.

eavprog
18.11.2017 16:49
#10527414
+1
не совсем согласен, но прислушаться стоит. хотя по поводу комментариев сразу буду оспаривать. сначала кидаю коменты. затем уже под каждым расписывают код. у меня так лучше программы пишутся.

ua9msn
18.11.2017 17:35
#10527456
+1
Самое неприятное это то, что сидит человек, попивает смузи и читает код из собеседований. И он уже весь свой смузи назад вытошнил, но «нормального» кандидата так и не нашел. Вот так вот. Увидел for — буээ не разбираясь. Точки с запятой нашел — всё, вы нам не подходите. Хотя может это и правильно. Зачем хорошему программеру такая компания…

GlebkaF
18.11.2017 19:30
#10527530
Спасибо за статью!
Не согласен только с if без скобок, в таких случаях стоит использовать тернарник, а если не получается, то стоит писать if со скобками, это исключает ошибки при правках этого куска кода.
Со всем остальным согласен, все перечисленное делает js код читабельнее и упрощает его рефакторинг.

OKyJIucT
18.11.2017 19:59
#10527548
Начал читать статью с ощущением "гуру поведает истину, всегда есть чему поучиться у опытных ребят" и даже собрался добавить ее по итогу в закладки, а оказалось, что даже мои взгляды на код (хотя мой опыт и не изменяется десятилетиями и десятками серьезных проектов, но я перфекционист) на порядок лучше, чем эти советы.

О таких советах пишут грамотные авторы книг по программированию в разделе "как делать не надо".

PaulMaly
18.11.2017 22:22
#10527628
Сорян, хотел удержаться, но совесем недавно сам с этим столкнулся и поэтому не могу ))))
```
const addOne = number => number + 1
const abs = number => {
  if (number >= 0) return number
  return -number
}
const abs = number => 
     number >= 0 ? number : -number
```
В целом не могу сказать, что я большой адепт фигурных скобок, но ведь есть и вполне прикладные причины их писать. Например, недавно у меня была довольно простая задача — законсолить все «ветки и ответвления» результатов в одном файле. Короче говоря плевое дело — пишем себе console.log и форматируем его читабельно. Но не тут то было, потому что код был написан именно так как вы советуете. И вместо того, чтобы просто делать перенос строки и вставлять мои логи, я был вынужден неимеверно изнасиловать себя и автокомплит веб-шторма, чтобы навставлять всех необходимых фигурных скобок, чтобы просто вставить логирование. Плевая задача превратилась в реальную проблему, потому что не так уж и хорошо с этим справляется редактор. Думаю те, кто сталкивался поймут о чем я.

p/s Сам люблю баловаться тернарным оператором, но стараюсь не использовать в результирующих операциях.

в будущем, я оформлю их в большой стайлгайд с кучей примеров плохого и хорошего кода.

Лучше не стоит))))
1. aamonster
  19.11.2017 01:24
  #10527780
  Ваш случай ещё хороший, бывает, люди обнаруживают, что скобок не хватает, уже постфактум (классическая ошибка: тело if из одной строки, дописали вторую)

novice2001
19.11.2017 01:31
#10527782
Я — художник, я так вижу.

tangro
19.11.2017 01:56
#10527794
+1

ankh1989
19.11.2017 04:07
#10527852
Автора хотя бы иногда посещает мысль, что возможно он не прав?

За свою недолгую карьеру программистом я побывал в разных командах иногда с прямо противоположными взглядами на то как писать код. Где то считают, что отступы надо делать табами, а другие яростно требуют ставить пробелы. Где то импорты сортируют по алфавиту, а где то по длине строки. Одни ограничивают длину строки и с религиозным фанатизмом считают, что должно быть именно 82 символа, а другие считают, что переносить строку — дурной тон. Одни пишут столько комментариев, что не видно кода, другие считают, что их код самодокументирван. Кто то требует 100% покрытие тестами, а кто то их не пишет вообще.

И знаете что я понял? Я понял, что всё это не имеет никакого значения. Что со своим уставом в чужой храм не лезут и что есть только одно правило: стараться придерживаться местных правил. Если вам на полном серьёзе говорят, что 10 вложенных if-else это лучше чем несколько return-ов, то не надо спорить — надо просто взять и написать 10 if-else, потому что в другом месте вам точно также будут доказывать, что несколько return-ов лучше, приводя не менее убедительную аргументацию.

Ещё мне кажется, что программисты делятся на два типа: те кто могут сделать что интересное, и те кто занимается крючкотворством от избытка времени — выравнивают отступы, подбирают более лучшие имена переменных и т.д. Вот вам пример кода: github.com/gcp/leela-zero/blob/master/training/tf/tfprocess.py — как вам имена переменных типа h_fc2? А как вам переменная "_" которую автор использовал в цикле? Или что скажите насчёт перменных rt_q вот здесь? github.com/torvalds/linux/blob/master/kernel/sched/rt.c#L122 Смеха ради, отправьте автору пул реквест с улучшенными именами переменных.
1. VovanZ
  19.11.2017 05:34
  #10527872
  А как вам переменная "_" которую автор использовал в цикле?
  В функциональных языках "_" — стандарт де-факто для идентификатора, который больше никогда не будет использован.
  
  policy_loss, mse_loss, _, _ = self.session.run( [self.policy_loss, self.mse_loss, self.train_op, self.next_batch], feed_dict={self.training: True})
  
  Автору нужно было распаковать кортеж из 4 элементов, но нужны ему только первые 2. Это вполне нормальная идиома для данного случая. Хотя, я бы написал даже вот так:
  
  policy_loss, mse_loss, *_ = self.session.run( [self.policy_loss, self.mse_loss, self.train_op, self.next_batch], feed_dict={self.training: True})
  
  Чтобы не повторяться — просто зафигачить весь "хвост" в список (и никогда его больше не использовать).
  1. ankh1989
    19.11.2017 07:57
    #10527906
    Имхо, даже _* — лишнее. Питон не позволяет просто пропустить ненужные переменные, поэтому пишут эти подчёркивания, а вот JS позволяет: [a, b] = [1, 2, 3] вполне валидный код.
  1. ankh1989
    19.11.2017 08:00
    #10527908
    Пример с питоном скорее был к тому, что h_fc2 следовало бы назвать hidden_fully_connected_layer_2 если следовать логике автора поста.
1. Finesse
  19.11.2017 05:38
  #10527874
  А как вам переменная "_" которую автор использовал в цикле?
  В программировании распространена практика нызывать _ переменные, которые не собираешься использовать. Например, когда язык программирования обязывает тебя записать результат выполнения функции куда-нибудь, а он тебе не нужен.

VovanZ
19.11.2017 05:33
#10527870
Не очень понимаю, почему все так придрались к else.

Я мало пишу на js, я питонист, но я бы тоже написал:
```
def abs(n):
    if n >= 0:
        return n
    return -n
```
вместо
```
def abs(n):
    if n >= 0:
        return n
    else:
        return -n
```
Выглядит компактнее и понятнее. ИМХО.
1. ankh1989
  19.11.2017 08:02
  #10527910
  Как то это не pythonic. Мои знания питона оставляют желать лучшего, но мне кажется, что более pythonic было бы return n if n >= 0 else -n
  1. VovanZ
    19.11.2017 09:04
    #10527920
    Ну это очень синтетический пример — ещё более pythonic — просто использовать встроенную функцию abs.
    
    Давайте я приведу ещё пример, чуть менее синтетический, но на псевдокоде (я буду использовать <вот_такие_комментарии> для сокращения и упрощения).
    
    Предположим, мы делаем REST API (ну или любой другой веб-сервис) и пишем функцию, которая обрабатывает HTTP запрос и возвращает запрошенный объект.
    
    Вариант с else:
    
    def handle_http_request(): if <проверка_авторизации>: return <401_unauthorized> else: if <проверка_прав_доступа> return <403_forbidden> else: if <проверка_существования_объекта> return <404_not_found> else: return <запрошенный_объект>
    
    Вариант без else:
    
    def handle_http_request(): if <проверка_авторизации>: return <401_unauthorized> if <проверка_прав_доступа> return <403_forbidden> if <проверка_существования_объекта> return <404_not_found> return <запрошенный_объект>
    
    Какой вариант более понятный и читабельный? Мне кажется, что второй.
  1. renskiy
    19.11.2017 10:04
    #10527940
    тернарный оператор в Python используют редко. Большинство считает его сложным для восприятия. Чаще используют его альтернативу (если это возможно):
    
    return n < 0 and -n or n
    
    Правда в таких случаях легко словить баг (например, если вместо условия "<" воспользоваться ">=")
    
    VovanZ
    19.11.2017 11:12
    #10527964
    Большинство считает его сложным для восприятия.
    Есть пруфы большинства?
    
    Чаще используют его альтернативу
    Ни разу не видел такой "альтернативы" и, тем более, не стал бы писать её сам. Слишком магично для питона. return n if n >= 0 else -n читается почти, как английский язык, а над return n < 0 and -n or n надо думать.
    
    renskiy
    19.11.2017 12:25
    #10528052
    пруфы гугляться очень легко:
    
    pythontesting.net/python/annoyed-ternary-operator
    
    www.pythoncentral.io/one-line-if-statement-in-python-ternary-conditional-operator
    
    Вся несуразность тернарного оператора в Python в том, что условие у него стоит не на первом месте.

lain8dono
19.11.2017 11:18
#10527966
На самом деле часть этого всего не лишена смысла. Но надо помнить, что у этих правил есть исключения. Всегда.

0) Не спорить о гайдлайнах. Они редко бывают совсем плохими, если они есть. Ну ладно. Они есть, пусть и редко. Но для тех, кто использует отступы пробелами в количестве не кратном степени двойки, есть отдельный котёл в Аду. Если вы считаете свои гайдлайны плохими — помните, что вы по крайней мере не из этих.

1) Не сокращайте слова. Правило не верно сформулировано. i, j, k и подобные — вполне себе годные сокращения. Если их использование понятно из контекста. Кроме того длинна имени переменной должна отражать время использования этой переменной и от общего их количества. Иногда имеет смысл написать больше, чтоб не путаться. Иногда наоборот. Кроме того есть и другие принятые ради общего удобства сокращения. Кстати img часто можно сократить до m (как в golang). Если это в любом случае одна переменная с таким использованием, то можно сократить. Если у нас похожие переменные, то не надо их называть так вообще. image мало о чём говорит само по себе. Ни чем не лучше чем любое другое. src на мой взгляд следует использовать вместе с dst в случае копирования одного на другое или подобного. Правильное правило:

Не сокращайте слова, если сокращение не очевидно. Если название переменной бессмысленно — им можно и нужно пренебречь.

2) Наличие и отсутствие ; — это только вопрос вкуса. Однако есть совсем мало мест, где символ требуется на самом деле.

3) Пример с abs. Первый вариант самый худший. Ранний выход из ф-ии лучше выглядит в случае, если ф-я достаточно длинная. Кроме того самым лучшим вариантом будет использование Math.abs, что очевидно. Что-то вроде такого:

Рассмотрите использование раннего выхода из объёмных функций.

4) Функциональный стиль всё ещё медленный в js? (В моём любимом ЯП наоборот). Обычный цикл for никогда не был медленнее других. Так или иначе — это вопрос конкретного случая. Если важно написать именно определённым способом вместо принятого в стилях проекта — это следует задокументировать. Если я прав на счёт производительности, то:

Используйте функциональный стиль везде, где производительность не критична.

5) Определённо не следует выделять лишнюю папку с единственным файлом index.js. Это банально лишний слой. Вот если там не один файл, а три и более — тогда определённо именно это и следует делать. В том конкретном случае лучшим будет:
```
component/
+-- button.js
+-- panel.js
L-- index.js
```
1. PaulMaly
  19.11.2017 15:43
  #10528232
  Отличный ответ! Наверное на кодинг стайл не тянет, потому что вы даете слишком много «опций», но сами рассуждения весьма здравые. Спасибо!
  1. lain8dono
    19.11.2017 16:46
    #10528324
    Наверное на кодинг стайл не тянет
    И не должно. Это общие рекомендации для создания кодстайла под свою задачу. Один кодстайл для всех — нонсенс. Каждый будет писать по своему. Я не претендую на истину в последней инстанции.
    
    PaulMaly
    19.11.2017 22:37
    #10528666
    Согласен, все верно пишете.

r-moiseev
19.11.2017 11:32
#10527980
Кодит автор аки боженька.

Вслед за выпиливанием; можно и {} во многих случаях выпилить. Но удобнее ли станет читать?

vanyaagent
19.11.2017 12:07
#10528030
Явный бред

AxisPod
20.11.2017 12:01
#10529226
Вот же жесть.
- ; — избавит от лишник проблем и наоборот позволит увидеть конец единицы трансляции
- скобки в параметрах лямбд для одного параметра наоборот позволяет с лёту определить сложные лямбды, в других случаях не стоит экономить скобки и гадать в плане приоритетов операций
- if-else, тернарный оператор — всё к месту, понятно, что надо избегать ёлочек, но не бывает белого и чёрного. никогда, всё от ситуации и временами одно хорошо, временами другое, временами ёлка будет лучше чем её отсутствие

Aries_ua
20.11.2017 12:18
#10529260
Скажите, а чем вам так цикл не угодил? Почему надо от него отказываться в пользу функционального подхода?

Давайте сделаем пример. Необходимо проверить существование строки «Вася Пупкин» в массиве объектов.
```
const testList = [
    {id: 1, name: "Pieter"},
    {id: 2, name: "Jhon Snow"},
    ...
    {id: 200, name: "Вася Пупкин"},
    ...
    {id: 1000, name: "Tony Stark"}
]

// Пример с циклом
let found = fasle

for (let i = 0; testList[i]; i++) {
    if (testList[i].name == "Вася Пупкин") {
        found = true
        break
    }
}

if (found) {
    // Делаем что-то
}

// Пример с функцией
if (testList.filter(item => (item.name == "Вася Пупкин")).lenght > 0) {
    // Делаем что-то
}
```
А теперь вопрос — что будет работать быстре? Попробуйте, и вы будете крайне удивлены. И красота это еще не все.

PS кстати, точки с запятой тоже не ставлю. Но тут больше дань Python, так как ранее на нем писал активно и много. Наверное надо себя отучить.
1. SergioShpadi Автор
  20.11.2017 12:50
  #10529324
  При функциональном подходе описывается то, что мы хотим получить, а при императивном — алгоритм, с помощью которого мы получаем результат. И второе для написания бизнес-логики нам абсолютно неинтересно.
  
  В вашем примере два способа не равнозначны. Правильнее будет так
  
  const found = testList.find(item => item.name === 'Вася Пупкин') if (found) { .......... }
  1. PaulMaly
    20.11.2017 12:53
    #10529330
    Функциональный подход — это зашибись, но для довольно ограниченного списка случаев. Ваш пример мне лично больше нравиться, сам часто использую reduce. С другой стороны, насколько я знаю, цикл будет работать значительно быстрее, в том числе из-за итарационных вызовов анонимной функции в вашем примере. Поэтому в некоторых «нагруженных» местах все равно придется отказаться от функционального стиля и использовать цикл.
    
    В любом случае, писать в полностью функциональном стиле с чистыми функциями — это дуба дашь. Я как-то пытался писать на чистом RxJS — это капец. Конечно, лично для меня.
    
    SergioShpadi Автор
    20.11.2017 13:08
    #10529352
    Как раз таки, наоборот. Императивное программирование незаменимо лишь в небольшом ряде случаев. В основном, когда очень важна производительность. В 3D-движках, операционных системах, драйверах и так далее. Но на JavaScript такие задачи обычно не решаются. На JS, в основном, разрабатываю веб-приложения. А при разработке веб-приложений нужно написать огромную кучу бизнес-логики. И производительность в данном случая совершенно некритична. А вот правильность логики и простоста ее дебаггинга и исправления крайне важна. С этой задачей функциональное программирование справляется гораздо лучше
    
    Aries_ua
    20.11.2017 13:21
    #10529376
    Боюсь я вас огорчу. О такой простоте можно говорить, когда у вас минимум элементов или просто говносайтик. Когда у вас количество компонентов, модулей, виджетов и страниц заходит за сотню другую (да да, это SPA для банковского или ERP/SRV приложения) вот тогда уже не до шуток, смузи итд. Здесь уже будешь думать и об оптимизации, перфомансе и прочих вещах. Что бы и софт был красив да и летал.
    
    PaulMaly
    20.11.2017 14:40
    #10529518
    Как раз таки, наоборот. Императивное программирование незаменимо лишь в небольшом ряде случаев. В основном, когда очень важна производительность. В 3D-движках, операционных системах, драйверах и так далее.
    
    Ну, что вы опять отсебячину заносите. Я вам сразу написал — мол был опыт, для меня это не айс, слишком сложно составлять дикие чейны из функций и код получается практически не читаемым. Еще раз обратите внимание на «для меня». Вы опять за свое — то ли от себя говорите, толи цитируете буклетик фанатов функциональщины.
    Но давайте попробуем все же разобраться.
    
    А при разработке веб-приложений нужно написать огромную кучу бизнес-логики.
    
    Верно, и учитывая, что человеку в принципе сложнее мыслить в функциональном стиле (https://habrahabr.ru/post/303312/), императивная логика пишется проще и визуально понятнее.
    
    И производительность в данном случая совершенно некритична.
    
    Опаньки, а с каких это пор у нас мобилки и смарт тв стали суппер производительными? Не, ну топовые модели 100К+ конечно да, но все же. Не говорите ерундны, пожалуйста — производительность софта это всегда критично. Если конечно это не софт для чиновников, они все равно часы отсиживают в основном.
    
    А вот правильность логики и простоста ее дебаггинга и исправления крайне важна. С этой задачей функциональное программирование справляется гораздо лучше
    
    Не согласен. Учитая, что в функциональном программировании нет понятия стейта — дебажить это не самое приятное удовольствие, имхо. Да, отсутствие стейта в целом может хорошо сказаться в принципе на кол-ве ошибок и багов, но непосредственно дебаг мне показался более сложным.
    
    Но уж раз вы любитель «реальных проектов», могли бы вы продемонстрировать какой-то более-менее осмысленный кусок кода на функциональщине? Мне интересно как вы работаете без переменных.
    
    SergioShpadi Автор
    20.11.2017 21:25
    #10530274
    У меня пет-проекты, в основном, на реакте и не содержат много преобразований. Но вот, для примера, код из моей маленькой библиотеки, устроняющей бойлерплейт для редакса.
    github.com/sergeyshpadyrev/react-redux-boil/blob/master/source/boil/index.js
    
    PaulMaly
    20.11.2017 21:31
    #10530284
    У меня пет-проекты
    
    А, вот они реальные проекты, о которых тут то и дело все говорят? Ясно-понятно.
    
    Но вот, для примера, код из моей маленькой библиотеки, устроняющей бойлерплейт для редакса.
    
    Во-первых, так и не понял где там функциональщина? Или вы под функциональным подходом понимаете использование функций? Тогда мы все функционально пишем))) Во-вторых, вы реально считаете что это понятный код?
    
    SergioShpadi Автор
    20.11.2017 21:54
    #10530314
    Всмысле? Чем вам пет-проекты не угодили? Я ж не буду вам сюда выкладывать коммерческий код.
    
    Вы можете не понимать этот код, потому что не знаете, что именно он делает. А так да, нормальный код. Не идеал конечно, но и не ужас-ужас. Средненький такой код.
    
    PaulMaly
    20.11.2017 23:26
    #10530432
    +1
    Всмысле? Чем вам пет-проекты не угодили?
    
    Тем, что пэт-проект !== реальный проект. Пэт-проект обычно пишет один автор, а раз так очень просто сказать, мол, «так никто не пишет» или «я ни разу не встречался с такими проблемами». Конечно нет, потому что вы один его пишете. Когда проект пишут хотя бы нескольк десятков человек, не приходится надеятся на «так никто не делает».
    
    Вы можете не понимать этот код, потому что не знаете, что именно он делает. А так да, нормальный код. Не идеал конечно, но и не ужас-ужас. Средненький такой код.
    
    Ну я как бы примерно понял что он делает. Я больше про читаемость и лично на мой взгляд — она очень низкая.
    
    Ну и опять же, вы обещали функциональный код, а прислали обычный императивный, просто слегка более невнятный за счет того, что вы туда внедрили ваше понимание функционального кода.
    
    michael_vostrikov
    20.11.2017 23:07
    #10530394
    return splitType[0] === settings.name && mutation ? mutation(state, ...action.payload) : state
    Когда эту строку читаешь, внутренний парсер несколько раз сбивается.
    
    return splitType[0] // возвращаем строку return splitType[0] === settings.name // а нет, bool return splitType[0] === settings.name && mutation // да, точно bool (ну, с учетом особенностей JS) return splitType[0] === settings.name && mutation ? // ой, тернарный оператор
    
    Лучше такие выражения в скобки оборачивать.
    
    return ( // возвращаем результат выражения в скобках return (splitType[0] === ...) // ага, последним был тернарный оператор, возвращается одна из веток
    
    novice2001
    22.11.2017 09:09
    #10532240
    Вот из-за таких писателей, для которых производительность некритична, становится все больше и больше сайтов, которые не тормозят только на топовых десктопных процессорах.
  1. Aries_ua
    20.11.2017 13:16
    #10529368
    Рекомендую вам сделать перфоманс тест и посмотреть на результат.
    
    И да, писать циклы "Писать императивно в 2017 году — это моветон" это не моветон. Это понимание того что и как работает. И что к чему надо применять. А потом новички начитаются вот таких глупостей и давай кодить попивая смузи. И смотришь потом, код красивый, а приложение тормозит.
    
    SergioShpadi Автор
    20.11.2017 13:30
    #10529382
    Под капотом у этих функций точно такие же императивные циклы. Да, производительность будет чуть ниже. Но скорость разработки и исправления багов при функциональном подходе в разы выше, а количество багов меньше. Достигается это засчет того, что при использовании функциональщины количество кода гораздо меньше, нету изменяемого состояния, а флоу гораздо очевиднее и проще.
    
    PaulMaly
    20.11.2017 14:43
    #10529524
    Но скорость разработки и исправления багов при функциональном подходе в разы выше, а количество багов меньше. Достигается это засчет того, что при использовании функциональщины количество кода гораздо меньше, нету изменяемого состояния, а флоу гораздо очевиднее и проще.
    
    Опять не вижу тега <imho/>, видимо все же буклетик цитируете. )))))

JavaScript, от которого не тошнит -91

Не сокращай слова

Не бойлерплейть

Пиши в функциональном стиле

Инкапсулируй модули

Не комментируй код

Располагай равнозначные элементы в алфавитном порядке

Вывод

Комментарии (175)

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор

SergioShpadi Автор