Каковы недостатки упругих вкладок? [закрыто]

Посмотрите здесь: типичная священная война на вкладках против пробелов .

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

Упоминаются ли даже упругие табуляторы в обсуждении табуляции и пробелов? Почему нет? Есть ли недостатки идеи упругой табуляции настолько серьезной, что никто никогда не реализовывал их в популярном редакторе?

РЕДАКТИРОВАТЬ : Я прошу прощения за то, что уделил слишком много внимания "почему они не упоминаются". Это было не то, что я хотел; этот вопрос, возможно, даже не по теме. Что я на самом деле имею в виду, каковы основные недостатки этого, которые мешают более широкому принятию заведомо полезной идеи? (в идеальном мире, где все это уже поддерживает)

(Оказывается, уже есть запрос на Microsoft Connect для реализации эластичных вкладок табуляции в Visual Studio , а также запрос в Eclipse . Плюс есть вопрос о других редакторах, которые реализуют эластичные вкладки табуляции )

Священные войны субъективны

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

Например, многим людям на стороне «пробелов» все равно не понравится, поскольку для достойного рендеринга требуется дополнительная часть логики в вашем программном обеспечении (например, просто просмотр набора изменений в веб-представлении вашего SCM).

Проблемы реализации

Но наиболее очевидная причина - это просто технический барьер для входа : это принципиально иное понятие, чем то, что было реализовано в течение ряда лет (если не десятилетий) в IDE и текстовых редакторах. Потребовалось бы переписать некоторые из них для обработки строк в совершенно ином порядке, что затрудняет работу старых и более крупных систем, которые имеют более высокие шансы на глубокую и жесткую связь в своем коде обработки строк. Это, однако, намного проще сделать , когда вы начинаете с нуля (думать о демо Ника или Go «s tabwriter пакет).

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

Мы заботимся достаточно?

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

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

Так что, если хочешь, помоги Нику.

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

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

Что происходит, когда я открываю ваши умные упругие вкладки в vim и редактирую их? Автоматически ли очищается вкладка или у вас все в порядке?

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

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

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

Но для первого я склонен просто отступать от всех аргументов на один дополнительный уровень, и это прекрасно работает со мной:

void foo(
    int x,
    int y,
    string z
)

И я не вижу какой - либо необходимости изменить это.

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

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

Если бы редактор их реализовал, я бы их не использовал.

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

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Что я хотел:

def foo( bar,
         xyzzy ):
    wibble()

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

Почему бы нам не сделать так, чтобы символ вертикальной табуляции (VT, ASCII 11) служил для указания использования упругих табуляторов? Он не имеет смысла ни в одном из основных языков программирования, но все же анализируется как допустимый пробел во всех из них, AFAIK.

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

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

Они не упомянуты, потому что они не реализованы в большинстве IDE текстовых редакторов; это новинка, мало используемая в проекте.

Пространства были использованы для разработки программ еще со времен перфокарт. Пришли вкладки, и кто-то явно подумал, что это хорошая идея (они ошиблись: p).

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

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

Я думаю, что они нашли бы много пользы, если бы IDE поддерживали их (Microsoft!). Как только люди обнаружат, что они могут шлепнуть свои цветочные ящики сбоку и сделать их хорошо читаемыми, они это сделают. Вы можете добавить больше комментариев к исходному коду внезапно (что может быть только хорошо).

Я полагаю, мы могли бы также добавить «всплывающие подсказки» к списку «было бы хорошо, если бы ...», чтобы ваши большие блоки комментариев можно было спрятать и легко просматривать при необходимости. Возможно, мы могли бы также иметь блоки комментариев, которые составляют часть документации (не вещи типа sandcastle, надлежащие читаемые пользователем фрагменты документации, которые были встроены в код, а не только заголовки методов)

Недостатки: это может привести к тому, что исходные различия будут выглядеть плохо, если группа строк будет выглядеть так, как будто они были изменены, когда действительно была изменена только 1 (если редактор сохранил файл с вкладками, преобразованными в пробелы). Или, если эластичная вкладка была реализована с одним символом (или, более вероятно, с 2 вкладками), тогда просмотр вашего источника за пределами редактора может выглядеть плохо.

Я думаю, что мне нравится идея, хотя «вкладка табуляции» в конце строки эластизирует блок комментариев и выстраивает все комментарии в последующих строках (которые имеют интервал между двумя вкладками) соответственно.

Вот как я это вижу: если бы большинство популярных инструментов уже поддерживали эластичные таб-стопы, многие люди использовали бы их. То же самое произошло с режимом навигации / редактирования vi, подсветкой синтаксиса и позже с Intellisense. В каждом случае устоявшаяся мудрость заключалась в том, что она бесполезна или не нужна, но она была реализована и взлетела.

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

Но это не означает, что функция не может быть принята постепенно. Каждый отдельный язык программирования принимался постепенно, хотя всей команде требуется новый компилятор и новая среда IDE, чтобы начать использовать его. То же самое верно для каждой аппаратной архитектуры и многих других примеров. Это также не тот случай, когда отсутствие интеграции с существующими инструментами является ограничителем показа: то же самое относится, например, к «унифицированному формату diff», который постепенно заменял ранее менее читаемый формат, который, тем не менее, понимали автоматизированные инструменты. (например, патч). Эти инструменты были обновлены с течением времени.

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

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

В целом, я думаю, что это хорошая идея, но лично мне бы это не понравилось.

Я только что испробовал реализацию эластичных табов-стопов в jEdit, которая удивительно хорошо работает с языками программирования, с которыми я знаком (в первую очередь с HTML / XML и C-подобными языками). Однако, с помощью кода Python, он выглядит так (пробелы используются вместо вкладок для иллюстрации выравнивания):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Для такого языка, как Python, который основан на пробелах, это нарушит условия сделки, если вы не отключите функциональность, предоставляемую эластичными табуляции. Редакторы, такие как Vim и Emacs, упрощают отключение большинства видов функций, если вы знаете название опции и как ее отключить, но для кода, подобного приведенному выше, потребуется отключить эту функцию.

Тем не менее, он отлично подходит для x86 ASM, C, C ++, Go, XML, HTML и других, которые не так сильно зависят от пробелов:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Я скажу, что диалекты Лиспа, такие как Scheme, имеют свои собственные соглашения, которые также заставляют упругие табуляции отображать «некрасивый» код. Если я изменю настройки табуляции в соответствии с соглашением из 2 столбцов и вставлю табуляции в необычных местах (между функцией и ее аргументами):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

по сравнению с более читабельным:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Конечно, этот не так плох, как пример Python, но он определенно снижает читабельность кода. Хотя мне очень нравится функциональность при кодировании на чем-то вроде C # или C ++, я ненавижу эту функциональность при кодировании на языке, таком как Python или Scheme, где пробелы являются функциональными и / или визуально полезными. Эластичные табуляции были созданы специально для того, чтобы быть полезными, не требуя отдельной утилиты отступов, но очевидно, что она предназначена не для всех языков программирования.

Emacs уже обрабатывает отступы при наличии закрытых скобок и автоматически выравнивает wilma с fred . Я понятия не имею, почему Eclipse не делает то же самое. Хорошо, у меня есть идея, но она не является обязательной.

Вы можете заставить Emacs выровнять комментарий тоже без особых проблем, но AFAIK никто, кроме вас, никогда не хотел этого.