Definitelytyped: Вкладки против пробелов?

Нет битвы. Используйте вкладки.

Голосую за пробелы!

Да начнется междоусобный конфликт! :улыбка:

ха-ха. нам это не нужно. Но вы знаете ... у нас не было бы этого разговора, если бы мы использовали вкладки, и каждый разработчик все равно имел бы свой код, идеально выровненный так, как он / она хотел (2 пробела или 4 пробела). Просто говорю.

Мне нравится таб.
но я думаю, что мы должны придерживаться настроек по умолчанию для VisualStudio.

Пробелы с размером отступа 4 (по умолчанию VS).
Настройте свою среду IDE на создание виртуальных вкладок для вас, и все будут довольны.
Мне просто не нравится видеть [tab] [tab] [space] [space] [space] для кода, который хочет выровняться со словом в строке выше.

Если кому-то захочется написать правило TSLint для обеспечения согласованного стиля (например: либо табуляции, либо 4 пробела, но не оба сразу), мы запускаем его в новом тестере (он поддерживает TSLint).

См. Также https://github.com/palantir/tslint/issues/122

Пространства! В библиотеках FWIW JS используются пробелы (angular / jquery)

Вероятно, это произошло из-за Крокфорда: http://javascript.crockford.com/code.html

Единица отступа - четыре пробела. Следует избегать использования табуляторов, потому что (на момент написания этой статьи в 21 веке) все еще не существует стандарта для размещения табуляторов. Использование пробелов может привести к увеличению размера файла, но размер не имеет значения в локальных сетях, и разница устраняется путем минификации.

Поскольку TS - это JS, нам действительно следует соответствовать.

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

Некоторое время назад на Reddit была статистика, когда кто-то проанализировал приличный кусок Github, и он был примерно 60% / 40% в пользу пробелов. Я и все места, где я работал до сих пор, были вкладками (хотя большая часть этого была AS3). Он отлично работает. Выравнивание кода - пустая трата времени, но при необходимости и там работают смарт-вкладки.

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

В какой-то момент мы сделаем # 2228, но это довольно большой шаг (привинчивает много атрибутов, чтобы мы могли позволить @ dt-bot делать это).

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

согласовано

Если вам когда-нибудь станет скучно, я советую прочитать запросы на перенос, сделанные для JSON.js. неизменно они представлены людьми, которые не знают о слегка капризных способностях Дуга. Всем им в упор отказывают :-)

Только что видел это: https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 по умолчанию - 4 пробела с вкладками, преобразованными в пробелы

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

Какое удовольствие @basarat!

CRLF немного глупы, но неважно.

Может, нам просто стоит пойти на это. Я попробую запустить typescript-formatter для всего и посмотрю, что получится.

Уважаемый господин, что за бойня ... Всего 562 файла .d.ts, при этом изменено 446 файлов ..

https://github.com/Bartvds/DefinitiTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitiTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

К сожалению, мы не смогли отобразить всю разницу, потому что было изменено слишком много файлов (446)

Хех.

И тесты тоже сделали:

https://github.com/Bartvds/DefinitiTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitiTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

К сожалению, мы не смогли отобразить всю разницу, потому что было изменено слишком много файлов (442).

Отлично. Итак, у нас есть технология, это была легкая часть. Но теперь нужно решить, хотим ли мы этого, потому что это окажет серьезное влияние.

За одну строчку атрибуция идет к черту. И если мы согласимся с этим, то, вероятно, нам следует принудительно применить форматирование в тестере. У меня есть настройка TSLint в тестере (но она отключена), так что она может многое.

Возможно, нам следует улучшить тестер до утилиты CLI, которая может запускать форматировщик и выполнять тесты удобным для использования способом (теперь он вроде как работает локально, но должен быть улучшен с помощью чистого API CLI и т. Д.).

Я говорю, чем скорее, тем лучше. Но хорошая новость в том, что вы не потеряете историю обвинений . Мне жаль, что GitHub не реализовал эту функцию в своем представлении различий.

Да, но это отстой, что git blame -w -M не работает в сети. Я только что написал об этом в службу поддержки Github.

@Bartvds , какой-нибудь ответ от GitHub ?!

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

Так что это может занять некоторое время, если вообще когда-нибудь.

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

концепция выравнивания кода (выравнивание по var и = в вашем случае) хороша. Но его сложно поддерживать при рефакторинге. Так что я им просто не пользуюсь. Также инструменты автоматического форматирования не уважают его, например , код автоматического форматирования в TypeScript.

Также для

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Добавьте новое свойство, и вам нужно _реформатировать_ все эти строки. Плохое изменение кода для проверки.

Ваш рабочий процесс может отличаться и может допускать это. Это действительно делает его намного более легким для чтения (код как искусство), но мне не удалось испытать, чтобы команды двигались по нему.

Это самое странное. Моя инстинктивная реакция на идею смешивания табуляции и пробелов - дрожать и думать: «Это просто грязно!»

Я знаю, что это совершенно иррационально, но совершенно искренне. Люди странные ...

@johnnyreilly вы стали жертвой распространенного заблуждения . Использование табуляции для отступа и пробелов для выравнивания НЕ то же самое, что _смешивание_ табуляции с пробелами. Вы явно не читали сообщение в блоге.

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

@basarat , я полностью с тобой согласен. Я редко работаю над проектами с выравниванием кода, но время от времени вижу это. Если бы вы могли каким-то образом заставить разработчиков в вашем проекте вообще не использовать выравнивание, я бы посоветовал сделать это. В противном случае, с пробелами для отступов, нет возможности для инструментов линтинга, среди прочего, отличить то, что было предназначено для отступа, от того, что было предназначено для выравнивания, за исключением синтаксического анализа кода в CST (способ излишнего).

Конечно, есть множество других причин не использовать пробелы для отступов в наше время. Редакторы хорошо справляются с табуляцией, но никогда с пробелами. Навигация по клавишам со стрелками, удаление, возврат - они просто не обрабатывают один отступ пробелов как одну единицу. Я использовал Visual Studio, Sublime, PHPStorm и Notepad ++, но у всех них есть фундаментальная проблема с пробелами для отступов.

Навигация по клавишам со стрелками, удаление, возврат - они просто не обрабатывают один отступ пробелов как одну единицу.

Навигация: я использую ctrl + клавиши со стрелками. Они прыгают пробелы (на самом деле все пробелы) + слова.

Для удаления / возврата: для выбора слова я использую расширенное слово (ctrl + w из значений по умолчанию resharper) и нераскрытое выделение (ctrl + shift + w). Мне редко нужно выбирать пробелы _inide_, просто используйте табуляцию (увеличить отступ) и сдвинуть табуляцию (уменьшить отступ).

@jedmao на самом деле я понял вашу точку зрения - я просто поделился своей инстинктивной (и иррациональной) реакцией. Я не сказал, что это имеет смысл: smile:

@johnnyreilly gotcha .

@basarat Я использую Home и End в некоторых сценариях с пробелами. Я пробовал использовать Ctrl + arrow key навигацию, но это не всегда работает. Вот почему я редко использую его из соображений последовательности мыслей. Рассмотрим следующий пример:

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Скажем, мой курсор находится в начале строки 3, и я хочу перейти к началу строки 2.

Используя вашу технику в Sublime, я мог бы сделать это одним из двух способов:

• Up , Hold Ctrl , Left , Release Ctrl (4 логических шага)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 логических шагов)

В Visual Studio второй сценарий можно сократить до 7 логических шагов.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 логические шаги)

С фактическими символами табуляции кратчайший путь составляет всего 2 логических шага без клавиш-модификаторов. Не может быть проще.

• Left , Up

Я не понимаю, как выбор слова поможет удалить или вернуть отступ через интервал. Я пробую это в Visual Studio безуспешно. Вот почему я создал плагин TabSanity для Visual Studio . К сожалению, мне неизвестны такие плагины для других редакторов.

С фактическими символами табуляции это всегда 2 логических шага без клавиш-модификаторов. Не может быть проще

: +1: Я вижу ваше преимущество. Однако, когда я редактирую этот комментарий, ctrl и т. Д. Работают так же, как мой VS, поэтому мои привычки сохраняются;)

Я не понимаю, как выбор слова может помочь в удалении или обратном интервале отступа.

Мое плохое, мое описание сбивало с толку. Игнорируйте бит выбора "слова". Просто сосредоточьтесь на I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Он отлично работает с отступами.

С фактическими символами табуляции это всегда 2 логических шага без клавиш-модификаторов.

Что о :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

Разве не будет переход от начала Age к изменению типа Surname т.е. string в предыдущей строке будет таким же, как сценарий Ctrl ?

@basarat Я Tab и Shift+Tab ; хотя обычно для нескольких строк кода. Думаю, вы могли бы сказать, что Shift+Tab - хороший псевдоним для нажатия клавиши backspace на вкладке, но он явно не такой простой или интуитивно понятный, как backspace .

Ctrl+Delete будет ближайшим псевдонимом к ключу Delete , но он может удалить более одного отступа; тогда как простая клавиша Delete на вкладке удаляет только один отступ. Иногда я работаю, а не другие, поэтому я не использую его вообще (умственная последовательность).

Мне, как и вам, также редко, если вообще когда-либо, нужно выбирать внутри пробела. Я никогда не предполагал, что буду. Я не выделяю пробел, а перемещаюсь по нему, чтобы куда-то добраться. В приведенном выше примере выравнивания я определенно использовал бы Ctrl + arrow key navigation. Вот почему, как я уже сказал, я редко использую Ctrl + arrow key навигацию, потому что сценарий, который вы указали, вероятно, является единственным случаем, в котором я бы его использовал.

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

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

Окончательный вывод? Я просто хочу внести свой вклад, какого черта вы используете?

Окончательный вывод? Я просто хочу внести свой вклад, что, черт возьми, ты используешь

Последовательно для каждого файла. Не смешивайте их в файле

@basarat, комикс неправильный. Все мы знаем, что парень из Apple будет использовать пробелы, а парень из Microsoft - вкладки.

@jedmao Я парень из мс и использую пробелы :)

Я считаю, что № 4211 - хорошее предложение.

Я бы предложил использовать 2 пробела, как это сделано в руководстве по стилю airbnb / javascript ...

Предложение: Используйте стандарты кодирования, установленные типизированной библиотекой. Если в типизированной библиотеке используются пробелы, одинарные кавычки и LF, сделайте то же самое в определении типа. Таким образом, мы можем избежать аргумента пробелов и вкладок.

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

Лично я предпочитаю пробелы (4) и двойные кавычки, но я не против использовать одинарные кавычки, если это означает, что все согласовано.

Могут ли пользователи pro-tab и pro-tab-space пойти на подобный компромисс?

Лично я предпочитаю пробелы (4) и двойные кавычки, но я не против использовать одинарные кавычки, если это означает, что все согласовано.

@ glen-84 исключительно для вашего развлечения ... вот почему команда компиляторов использовала двойные кавычки: https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Работает на всех языках, что снижает когнитивную нагрузку

Я лично использую одинарные кавычки, поскольку все больше и больше пишу исключительно на TypeScript: rose:

Я думаю, что это также немного более разборчиво, и оно составило 57% против 43% (небольшая разница), но я думаю, вам нужно где-то провести черту. знак равно

Мне нравится точка @jedmao на вкладках для отступов и пробелов для выравнивания.

Полное раскрытие: я приехал из Go-land, где у нас есть go fmt и никаких обсуждений о табуляциях или пробелах никогда не было ... Это табуляции для отступов и пробелы для выравнивания, и это работает очень хорошо: +1:

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

@hinell, почему это важно, если вкладки отображаются по-разному в разных редакторах? Этого не должно быть, если табуляция используется «только» для отступов.

Я предпочитаю вкладки, особенно из-за этого: http://nickgravgaard.com/elastic-tabstops/

Оказывается, есть еще одна причина использовать вкладки: доступность для разработчиков .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/