Как стать автором Хабровчане vs. цифровые сервисы банков: итоги
Потоки
Все потоки Разработка Администрирование Дизайн Менеджмент Маркетинг Научпоп
Комментарии 64
Так же работаю с Prettier, но заметил, что эта штука не до конца понимает чейны и уж слишком разворачивает объекты конфигураций json
+3
У меня для вас плохие новости. На момент написания это комментария вы находитесь в меньшинстве.
+2

Спасибо, не надо.


    <div
      className="HelloWorld"
      title={`You are visitor number ${num}`}
      onMouseOver={onMouseOver}
    >

(из официального примера)

0

Придерживаемся такого стиля в форматировании xml в Android. Сначала было непривычно, потом стало норм. Особых минусов нет.

+3
очень удобный стиль — когда надо добавить или удалить свойство — просто добавь или удали строку, да и в jsx свойств может быть очень много
+4

Единственное, что меня смущает в а автоматических форматтерах — то, что они не могут распознавать случаи, когда программист сам выставляет пробелы для форматирования. Они их убирают и код наоборот становится нечитаемым.

+2

Для таких случаев можно поставить коммент prettier-ignore. Prettier оставит форматирование этого куска как и было:


// prettier-ignore
matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
);
+1
В Java стиль чистого кода появился с лёгкой руки Боба (Robert Martin), и не говоря про JavaCodeConvention.
Возможно, и у JavaScript появиться свой евангелист…
+1
Так привыкла писать код с определенными стилевыми правилами, что уже делаю это на автомате.
Кода вижу что-то вроде этого:
function getTotalPrice(sum){
	var price=sum || 0,
		tax = 5;
	price+= tax;
	var delivery = 3;
	if(price<10) price += delivery;
	return price;
}

Не могу удержаться и не переписать с «правильными» пробелами, скобками и тд:
function getTotalPrice(sum) {
    var price=sum || 0,
          tax = 5,
	  delivery = 3;

    price += tax;

    if (price < 10) { 
        price += delivery;
    }

    return price;
}

Есть главы в книгах Стефанова «JavaScript. Шаблоны » и у Крокфорда «JavaScript. Сильные стороны»(где он про JSLint пишет) рекомендации как оформлять код.
+2
В итоге один оператор равенства отбит пробелами, а самый первый — нет.
+3

Было бы лучше, так:


function getTotalPrice(sum) {
    var price    = sum || 0,
        tax      = 5,
        delivery = 3;

    price += tax;

    if (price < 10) { 
        price += delivery;
    }

    return price;
}
-1

нет, пожалуйста, не надо! Нет ничего хуже, чем центрирование кода относительно знака равенства.


Потом придется добавить еще одну переменную с именем подлиннее, и придется переформатировать весь блок кода, создавая большой diff и потенциальные merge-конфликты.

+6
нечего даже обсуждать — у Prettier’а несколько опций;

Это не совсем правда. Опций немного, но они очень холивароспособствующие.


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

+2
Несовсем понятно, с чего вдруг холивару начатся — как техлид сказал код оформить, так все и сделали, точка. Никакого холивара, все заняты работой, а не ерундой.

Про development standards никогда не слышали? Простой документ с элементарным набором правил по разработке (включающий, но не ограниченный, naming conventions и тем самым форматированием), который почетно вручается каждому программеру, пришедшему на проект/в компанию. Тому, кто не блюдет — по шапке. Проблемы?
+1

Странно, если все так легко, то отчего же спор "табы против пробелов" до сих пор не закончился? Сходили бы все разработчики к мудрейшему техлиду, и узнали у него как надо.


Но почему-то так не происходит, а любой пост на эту тему набирает немало комментариев, например, вот этот.

+1

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

+1
Подскажите пожалуйста, название темы для sublime, на изображении к посту.
0
Есть мысль, что возможно следовало бы просто учитывать это всё в самом языке.

Например вот сейчас в Питоне можно написать

def f(a, b,  c):
    pass

а можно

def f(a,
    b,
    c):
    pass

или даже

def f(a, b,
    c):
    pass


и в случае длинного (зачастую из-за названий параметров, указания дефолтных значений, типов и т.п.) списка параметров приходится прибегать ко второму или третьему варианту, но в случае короткого используют первый.

Не лучше ли было бы, если бы второй или что-то типа него было бы единственно разрешённым? Разнообразие в этом лично мне кажется «untidy», а третий вариант (который зачастую выбирают IDE при автоматическом форматировании) как по мне и вовсе исчадие «ада перфекциониста».

Ни в коем случае не настаиваю и сам не уверен, просто подумалось, решил вынести на суд коллективного разума.
+1 
def f(a, b,  c):
    pass

— хороший вариант, если нет комментариев


def f(a,
    b,
    c):
    pass

— плохой вариант, если нет комментариев, но, который легко превращается в очень хороший, если добавить комментарии


def f(a, # комментарий a
    b, # комментарий b
    c): # комментарий c
    pass # итоговый комментарий

PS с Питоном не знаком, просто нагуглил аналог // из C++

0
Любопытно, кстати, почему люди вообще до сих пор используют текстовое представление для хранения программ. По-моему тут на лицо сращивание данных и форматирования в одну сущность, которого вроде всегда стоит стараться избегать. Почему вместо этого не хранить типы, переменные, функци и т.п. в качестве записей, скажем, в реляционной БД, с указанием отношений между ними, имён и инициализационные значений как отдельных полей, а для каждого разработчика рендерить как ему больше нравится?
+1

Тогда уж хранить код в виде AST, а в редакторе разворачивать с применением персонального файла стилей.
Минус данного подхода: как хранить AST в системе контроля версий?

0
А что мешает сделать diff для AST? А уж если некий формат описания AST станет стандартным то и вообще все будет замечательно.
0
AFAIK, самая большая проблема — это время обработки:
1. Размер деревьев. Число токенов на порядок-два (зависит от ЯП) больше числа строк.
2. Деревья — двумерные структуры. СКВ работают преимущественно с классическими операциями Левенштейна (добавить, удалить, заменить строку). Много ли Вы знаете СКВ, которые бы отличали <удалить строку A №5 + вставить строку A перед строкой B №4> и <поменять местами строки B №4 и A №5> и корректно сливали эти патчи с другими? Для AST необходимо же исходно поддержить как горизонтальные операции (добавление/удаление дочернего поддерева), так и вертикальные (замена поддерева его дочерним поддеревом/замена поддерева T на C[T] для некоторого контекста C[] с одним подстановочным местом). Вроде бы это обстоятельство меняет асимптотическую сложность.

И ещё обращаю внимание, что получение диффа — более простая задача, чем построение модели (в т.ч. с конфликтным/бесконфликтным слиянием патчей) СКВ.

P.S. Я полностью согласен с последним: если когда-то СКВ научатся работать с AST и будет унифицированный формат деревьев, инструменты программирования шагнут на принципиально другой уровень удобства.
0
НЛО прилетело и опубликовало эту надпись здесь

Как-то решение сразу не пришло в голову.
Можно сформировать отдельный файл стилей для хранения.
При загрузке переформатировать в пользовательский формат, при сохранении — в машинный.

+1
Еще при изучении и рефакторинге больших программ хочется уметь работать с кодом чем-то типа SQL или SPARQL запросов.
0
Использую автоформатирование, которое даёт мне JetBrains. Неплохо справляется со своей задачей. И ESLint сбоку ещё повесил, чтобы в случае косяков со стороны IDE форматтера, я мог это сразу увидеть. Поэтому для себя не вижу смысла использовать ещё и Prettier.
0
Суть prettier в том, что ты пишешь код как пишешь, а потом одной комбинацией клавиш приводишь его вид к общему стандарту в команде
+1

Я тоже пишу код, как хочу, а потом нажимаю Ctrl+Alt+L (В поиске: Reformat Code) и привожу его к общему стандарту. Помимо этого, PHPStorm неплохо синхронизируется с настройками .eslintrc.json.

+1
Сейчас изучаю язык ELM, в котором есть стандартный форматер elm-format, вставляющий кучу лишних пустых строк и разбивающий строки без пользы для читаемости. Не все любят такой стиль, и появился сторонний продукт elm-format-short, который более экономно относится к месту на экране. Мне удобно видеть сразу больше кода, держать в уме не поместившееся на экран памяти не хватает, я быстро перешел на него. При этом идея сделать форматер настраиваемым в комьюнити поддержкой не пользуется.
Я вот думаю, хорошо бы если бы IDE при сохранении форматировала стандартным образом, а при загрузке — по настройкам пользователя. Тогда бы и взаимодействие в команде не страдало бы, и редактировать код в своем стиле было бы удобнее.
0

Делайте форматирование по стандартам в pre commit hook, а каждый разработчик настроит в своей IDE автоформатирование по своему вкусу.

0
очень раздражает автоформатирование GO. он просто заставляет следовать егоному стилю.
так и стремится удалить лишние строки, пробелы, выстроить выражение по своему образцу.
лучше бы сделали подобную опцию опциональной. ломать через колено это неприятно, после других то языков.
-1
Пишу на Java в Intellij IDEA, и там код можно автоматически отформатировать одним сочетанием клавиш. Довольно удобно. Неужели для JS нет такой же удобной IDE? (WebStorm, не?)
PS Хотя и вручную я тоже стараюсь придерживаться какого-то (чаще всего наиболее читабельного) форматирования кода.
0
Причина, по которой приходится использовать стандартное авто форматирование кода это использование систем контроля версий (git, svn и пр.), которые универсальные и работают с текстом. Если форматирование изменится, то это будет уже новая версия кода. Поэтому для командной разработки кода лучше всего применять авто форматирование.
0
Первый и второй вариант одновременно — большая часть форматируется «роботом», если где-то было трудно это сделать руками, меньшая — руками, так как там форматирование улучшает понимание, а «робот» его портит.
+1
В конце концов понял, что мне в целом все равно (хотя конечно же есть вид, который мне нравится), и, гораздо важнее, чтобы стиль был одинаковый у людей, с которыми работаешь. Иначе сбиваешься при чтении в разных местах проекта.
То есть важнее договориться одинаково, чем сделать как то особенно правильно.
В этом смысле имеет смысл смотреть на стандарты для языка — от мейнтейнера, популярной ide или стандартных модулей.
+1

Перешел на prettier с standardJs — Это просто божественно — да, в нем мало настроек, по началу это бесило (например нельзя в реакте сделать ковычки на пропсах одинарными) — но сейчас я понимаю что вообще больше руками не форматирую код — все делается автоматически за меня.


Я не представляю себе ситуацию чтоб я вернулся к ручному форматированию.


Но у преттиера есть минус — он немного сырой и кое-где ведет себя странно, с теми же промисами

+1
У нас практика показала, что если prettier что то форматирует странно, это значит изначально код написан сильно криво. Я своих ребят ещё какое-то время отучал от фраз типа «это претир так сформатировал». Писать надо так чтобы форматировалось нормально. Выносить вычисления в константы, не совмещать вычисления с возвратами, особенно тринарники. И всё сразу нормально форматироваться начинает.
+2

Дак нет, он реально плохо чайнит промисы.
Вроде в новых версиях это поправили каким-то костылем, что-то типа "если есть слово than значит чайним все на новую строку, если слова нет то чайним в одну если помещается и меньше двух точек, инача все на новую строку"


Собственно из-за этого он переносит в моем случае адрес запроса на новую строку


api
    .get(`/ajax/report/${id}/info`)
    .then(res => {
      // Handle

Хотя я привык к чему-то типа


api.get(`/ajax/report/${id}/info`).then(res => {
      // Handle
0
В одной американской компании, в которой работал шесть лет был первый упомянутый стиль оформления для кода на C++.
Заголовок спойлера
if (food == 'pizza')
{
    print('Pizza ;-)');  
}
else
{  
    print('Not pizza ;-(');
}

(часть корпоративного стандарта). Это довольно удобно, претензии неясны. Хорошо видны логические блоки, особенно, при нескольких вложенностях.

Есть еще кое-что, что никто кроме меня не делает. Я всегда использую двойной пробел перед комментарием в конце строки.
Я думал, это улучшает читабельность кода. Но, на самом деле, это делает кодовую базу несогласованной, потому что остальные разработчики ставят только один пробел.

Например с точки зрения python pep8 рекомендуется как раз делать два (как минимум) пробела перед # в инлайн-комментариях.
выдержка из pep8
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.



В итоге, не стоит полагаться на какие-то абсолютные правила, а имеет смысл договориться в и приянть стиль оформления в своей команде. Не вижу проблем, разработчики не будут явно придумывать обфускаторы, а сделают так, как читабельнее для них, и пусть это будет отличаться он неких догматических «стандартов».
+2

Намного лучше и удобнее


if (food == 'pizza'){//комментарий if
    print('Pizza ;-)');}
  else{//комментарий else
    print('Not pizza ;-(');}
another.code();//следующий код с начала строки

— выделяется целиком весь блок if-else, и видно, где он кончается
— выделяется, где else
— компактно, и на экране можно одним взглядом охватить больше кода

-6
А уж как «удобно» мержом добавлять новую строчку перед закрывающей скобкой!
+3

Можно и так:


if (food == 'pizza'){//комментарий if
    print('Pizza ;-)');}
  }else{//комментарий else
    print('Not pizza ;-(');
  }
another.code();//следующий код с начала строки

PS судя по минусам в Карму, у Вас явно не хило бомбануло, от указания недостатков варианта:


if (food == 'pizza')
{
    print('Pizza ;-)');  
}
else
{  
    print('Not pizza ;-(');
}
+1

Вариант


if (food == 'pizza')
{
    print('Pizza ;-)');  
}
else
{  
    print('Not pizza ;-(');
}

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

+1

Удобнее всего


if (food == 'pizza'){
    print('Pizza ;-)');  
}
else{  
    print('Not pizza ;-(');
}

Тогда при сворачивании блока я вижу его первую строку, строка с "{" не маячит. А в развёрнутом виде хорошо видна структура блока.

+1

Отличная идея! Про сворачивание я-то и не подумал...

+1
С моей точки зрения идеальным вариантом, исключающим большинство холиваров, был бы такой подход: при загрузке в редактор — персональное автоформатирование, а при сохранении/коммите — стандартизированное форматирование. В обоих случаях должно происходить полное переформатирование без учета текущего формата. Исключением могут быть специально обозначенные блоки, которые никогда не переформатируются, только вручную. Тогда каждый будет работать с удобным и привычным ему лично форматом, а стандартизированный формат позволит более корректно проводить мерджи и позволит избежать различных проблем, присущих, например, JS. Причем персонализированный формат должен быть максимально настраиваимым, а стандартизированный наоборот не должен иметь натроек совсем.
+1
Я бы даже сказал, что это чем-то напоминает загрузку и сохранения файлов в текстовых редакторах, где сам файл представляет некий стандартный формат, а в редакторе виден удобный для работы текст.
+1
В С-подобных языках открывающая фигурная скобка избыточна. Все операторы, кроме отдельного блока, и так имеют четкое начало — ключевое слово и следующее за ним условие, выделенное скобками.

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

Информация

Дата основания
Местоположение
Россия
Сайт
www.edsd.ru
Численность
31–50 человек
Дата регистрации

Блог на Хабре

Ваш аккаунт

Разделы

Информация

Услуги

Настройка языка
Техническая поддержка
© 2006–2021 «Habr»