У чому полягають недоліки пружних стільниць? [зачинено]


83

Подивіться тут: типова свята війна на вкладках проти просторів .

Тепер подивіться тут: еластичні настільні стільниці . Всі вирішені проблеми, а також додано купу дуже корисної нової поведінки.

еластичні накладки

Чи згадуються еластичні вкладки навіть у обговоренні вкладок та пробілів? Чому ні? Чи є недоліки еластичної ідеї табустопа настільки серйозні, що їх ніхто не реалізував у популярному редакторі?

EDIT : Вибачаюсь за те, що ставте занадто великий акцент на "чому вони не згадані". Це було насправді не те, що я задумав; це питання, можливо, навіть поза темою. Що я насправді маю на увазі, які найбільші недоліки цього перешкоджають більш широкому прийняттю явно вигідної ідеї? (в ідеальному світі, де все це вже підтримує)

(Виявляється, вже є запит на реалізацію еластичних вкладків Microsoft Connect для Visual Studio , а також запит у Eclipse . Плюс є запитання щодо інших редакторів, які реалізують еластичні вкладки )


4
Це було б чудовим питанням для ux.stackexchange.com
JonnyBoats

11
Вони ніколи не згадуються в дискусії "вкладки проти пробілів", тому що працюючий програміст майже не може використовувати ці речі. Можливо, якщо у вас була реалізація Eclipse, VS, gvim та emacs, це може змінитися.
Пол Томблін

2
Мені дуже подобається ідея, але це лише тоді, коли ти живеш з нею місяць або близько того, що ти справді знаєш, що таке підводні камені. Як і все колись, гарантовано є випадки, коли це робить те, чого ви не очікували ...
Кріс Берт-Браун

3
@ ChrisBurt-Brown Це завжди ризик, так. У IntelliSense є і свої підводні камені, як і передача тексту, коли ви цього не хотіли. Однак в цілому IntelliSense в C # виграв великий жир.
Роман Старков

4
Я хочу цього в блокноті ++ ... Я хочу цього зараз
Бен Брока

Відповіді:


32

Святі війни - суб’єктивні

Еластичні вкладки Ніка - це дивовижна концепція, яка може допомогти багатьом людям погодитись на ефективне рішення, хоча я дуже сумніваюся, що це повністю закінчить цю Священну війну: це, зрештою, також справа смаку, і багато програмістів не рухатимуться дюйм від своєї позиції з цього приводу, навіть ціною компромісу. Тож це було б першою причиною.

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

Питання впровадження

Але найбільш очевидною причиною є лише її технічний бар'єр для вступу : це принципово інша концепція від тієї, що впроваджується протягом ряду років (якщо не десятиліть) в IDE та текстових редакторах. Було б потрібно переписати деякі з них, щоб обробити лінії досить іншим способом, що утрудняє старі та більші системи, які мають більший шанс зазнати глибокого та щільного з’єднання у своєму коді обробки рядків. Це, однак, набагато простіше зробити , коли ви починаєте з нуля (думати про демо Ніка або Go «s tabwriter пакет).

Щодо особистого анекдоту, я пам’ятаю, як деякий час назад звертався до автора, щоб запитати, чи є підтримка emacs у полі зору, і в цьому конкретному випадку він згадував це як причину того, що він не банальний. Він також попросив допомогу громади, щоб допомогти втілити цю функцію та довести її до широких мас.

Чи нас турбує достатньо?

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

Якщо ви цього хочете, вам доведеться боротися за це. Що можна зробити у програмному забезпеченні з відкритим кодом. І якщо ви зміните достатньо цих, закритим вихідним кодом доведеться стежити, ризикуючи втратити якусь частину своєї бази користувачів, якщо все-таки така невелика її частина.

Тож, якщо ви цього хочете, дайте руку Ніку.


Мене часто цікавить, як інші функції "це приємно, але дуже незначно" коли-небудь перетворюють їх на такі продукти, як Visual Studio. Схоже, хтось із колективу просто знайшов час, щоб реалізувати це з особистих причин. Придумайте, наприклад, ввести кілька рядків у Visual Studio; це не так, як просили про це десятки тисяч людей, але мені це подобається.
Роман Старков

3
@romkyns: Що стосується багатьох речей, це потребує або одного тихого інсайдера, або тисячі голосів, що кричать біля воріт.
хайлем

35

Багато разів мені доводилося битися з текстовим процесором, щоб документ виглядав так, як я хочу, без якихось прихованих автоматичних правил, що контролюють розміщення моїх слів. Я не хочу витрачати ні секунди, намагаючись зрозуміти, чому редактор наполягає на тому, щоб розмістити ці слова там.


11
Я також не співчуваю цим настроям, оскільки такі правила насправді і мене зривають. Але це по-різному. Перший: Як і зараз вкладки, вам не потрібно їх використовувати, якщо цього не хочете. Ви можете залишити текст своїх колег у спокої, якщо він їх використовує. Друге: Еластичні вкладки не мають прихованих правил, але очевидно очевидні. Поведінка цілком природна - можливо, навіть більш природна, ніж традиційні вкладки, які трапляються в якомусь довільному, як правило, неактуальному положенні в тексті. Ось чому ніхто більше не використовує вкладки для окрім відступів.
Тімві

10
@Timwi: Питання полягало в тому, щоб перелічити недоліки. Я робив.
mhoran_psprep

14
Це може бути не очевидно з GIF, але єдине, що з'ясовується, - це те, що при натисканні кнопки "TAB" все, що відбувається після, вийде правильно вертикально вирівняним. Це не що інше, як текстовий процесор. Просто спробуйте фактичну інтерактивну демонстраційну версію за посиланням, яке я розмістив, і ви побачите, наскільки це природно.
Роман Старков

3
@mhoran_psprep: Досить справедливо, я ціную ваш внесок. Я думаю, ми розглядали різні тлумачення питання. Ви перераховуєте недоліки себе за допомогою функції, тоді як я думав, що це стосується недоліків впровадження функції (тобто надання її доступною, а не обов'язковою ).
Тімві

27

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

Що станеться, коли я відкрию ваші розумні еластичні вкладки inim і редагую її? Чи вкладка автоматично очищається чи у вас залишається безлад?

Як я бачу, основні недоліки - це, можливо, порушення розрізнення, керування версіями та не сумісність з редакторами, які не підтримують їх. Для їх підтримки може бути багато модифікацій коду, і є важливіші речі, ніж функція "ще одна вкладка для форматування коду". Зрештою, ми всі можемо використовувати те, indentщо робить усе вищезазначене, якщо служить пам'ять.


9
Яке відстале мислення. Давайте не мати ніякого прогресу , тому що улюблені старі, застарілі інструменти людей не можуть впоратися тільки поки ! (Зрозуміло, що іронія полягає в тому, що ці інструменти (наприклад, vim) є відкритим кодом, тому якби це було для вас дійсно важливо, ви могли (і, мабуть, повинні ) додати до нього еластичну підтримку табустопа)
Timwi

14
@Timwi: Ви абсолютно не вистачаєте моменту, який я робив. Що відбувається, коли ваш файл коду розбирається чимось, що не знає про еластичні вкладки? Ви закінчилися безладом чи вони можуть впоратися? Що з контролем версій та різницею? Просто бажаючи, щоб усі інструменти підтримували функцію $ нереально, навіть якщо ці інструменти є відкритим кодом.
Сардатріон

14
@Timwi: Ви припускаєте, що всі знаходять еластичні вкладки настільки ж приголомшливими, як ви думаєте. Це може бути неправдою.
Сардатріон

7
@Sardathrion має рацію. Що станеться, коли мені доведеться віддалятися на свій * nix-сервер без встановленої системи вікон і мені потрібно вивчити якийсь код за допомогою Vim / Emacs / Pico / Що б там не було? Якщо є механізм, який би читався, це було б добре ... інакше це був би кошмар. Я не бачу, щоб користь еластичної вкладки перестала бути такою корисною. Я вже можу автоматично відформатувати свій код, щоб подивитися, як він повинен бути в IDE, які я використовую.
Ріг

7
Точка управління версіями хороша - я не думаю, що люди не будуть цінувати редактора, який мовчки починає змінювати розміщення / формат коментарів у коді довільно далеко від модифікованого коду (див. Розділ пурпурового кольору в анімованому ОП gif). Було б корисно мати референтну реалізацію, з якою можна пограти, але те, що я бачу поки що, не примітно - Emacs вже робить багато цього, лише за допомогою декількох додаткових натискань клавіш (що, певно, добре).
mcmcc

13

Якщо чесно, я не вважаю їх корисними, коли переживаєш первісне хвилювання. Наприклад, мені все одно не подобаються коментарі в кінці рядка - я завжди розміщую свої коментарі в окремому рядку. З цим еластичні вкладки втрачають своє основне використання.

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

Але для першого я схильний просто відкласти всі аргументи на одному додатковому рівні, і це працює зі мною цілком чудово:

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

І я не бачу ніякої необхідності змінювати це.

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

Підсумовуючи, еластичні вкладки для мене абсолютно нульові . Це, звичайно, дуже особисті переваги, які можуть відрізнятися, але я вважаю, що це працює добре, і я гадаю, що відсутність підтримки еластичних вкладок - це тому, що інші люди думають аналогічно.

Якщо редактор буде реалізовувати їх, я все одно не використовую їх.


Вдячний. Здається, що ви могли б із задоволенням використовувати шрифт змінної ширини, якщо просто цього хотіли, оскільки ви все одно не вирівнюєте нічого, крім початку рядка. Насправді Visual Studio має досить гарну підтримку для цього, і збільшення читабельності приємне.
Роман Старков

1
@romkyns У нас були дискусії з цього приводу, і протягом однієї я деякий час я намагався використовувати пропорційний шрифт для програмування. Підсумком було те, що одноразові шрифти працюють краще, навіть якщо нехтувати відступом. Крім того, я зараз працюю виключно у Vim та консолі, жоден з яких, ймовірно, ніколи не підтримуватиме пропорційні шрифти.
Конрад Рудольф

1
@romkyns Тим не менш, ці проблеми вирішуються (або, можливо, навіть вирішуються, пропорційним шрифтом, призначеним для програмування). Але я все ще не бачу необхідності.
Конрад Рудольф

13

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

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

Що я хотів:

def foo( bar,
         xyzzy ):
    wibble()

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


Домовились. Реалізація Ніка зовсім не працює для таких мов, як Python.
Роман Старков

3
Чому б це не спрацювало? Це не є принциповим обмеженням, алгоритм просто повинен знати мову. Але певною мірою це справедливо і сьогодні, наприклад, Vim визначає різні правила відступу залежно від мови. Це міг легко вмістити відступи Python.
Конрад Рудольф

1
@KonradRudolph Ні, вони не змогли. Малюнок еластичних вкладок - це можливість автоматично відступати / відступати групи тексту разом. Один з простих прикладів - це закінчення висловлювання "якщо": Ви намагаєтесь відмінити відступ, оскільки ви виходите з цього виступу, але "розумні" еластичні вкладки вирішили, що ви мали намір також відмінити відступ рядка або двох вище, тощо. і так далі ... І якщо вам доведеться чітко групувати текст разом, то - який сенс? Для цього краще працювати, ніж самостійно виправляти відступи ...
Ізката,

1
@Izkata Відключення вручну (повинно) просто закінчити поточну групу. Чому б ви коли-небудь керували відступом, коли пружні вкладки зупиняються вручну? Ви б цього не зробили, тому алгоритм знає, що коли ви це зробите, це закінчити блок, а не відмежувати відступ на вищезазначений блок.
Конрад Рудольф

1
О, хороший пункт. Гм ... може, ти міг би подвоїти аргументи вдвічі? Отже, тоді wibble()матиметься лише одне відступ і тому не було б узгоджено з аргументами функції?
Ajedi32

12

Чому б нам просто не зробити так, щоб символ вертикальної вкладки (VT, ASCII 11) слугував для позначення використання еластичних вкладок? Він не виконує жодних цілей у будь-якій мові програмування, але в усіх них розбирається як допустимий пробіл, AFAIK.

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

Існуючі текстові редактори зазвичай відображають гліф або єдиний пробіл замість вертикальної вкладки. Це не ідеально, але невелика ціна, яку потрібно заплатити, ІМО.


10

Вони не згадуються, оскільки вони не реалізовані у більшості IDE текстових редакторів; вони новинка мало реального використання в проекті.

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

У дні, коли більшість сучасних редакторів можуть автоматично перетворювати вкладки в пробіли ... вони досить безглузді.

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


Я очистив коментарі, коли вони зійшли в образу.
ChrisF

1
Щойно я подумав, я зазначив, що головна причина, чому мені подобається ідея еластичних вкладків, не тому, що вона вирішує проблему вкладок та пробілів, а через поведінку, показану в GIF в оригінальному питанні; автоматичне вирівнювання без болю. Крім того, для VCS відрізняється додаткова перевага в тому, що в цьому прикладі не було потрібних змін пробілу.
Ajedi32

"Необхідно встановити ще один інструмент ..." - недостатньо гарний аргумент ... Начебто вже недостатньо інструментів, які вже використовуються.
Milind R

@MilindR Незалежно від того, чи вважаєте ви це досить гарним аргументом чи ні, це причина, чому (на той час три роки тому) я не зацікавився б цим. Існує багато інструментів, які роблять щось корисне, це не привід додавати ще один, який насправді нічого не додає у ваше оточення.
TZHX

Подібне ставлення, тому такі компанії, як MS, вирішують змусити користувачів до нових UXes ... Я здригаюся думати, що буде, якби те саме ставлення було застосовано і до дискети -> CD переходу.
Milind R

4

Я думаю, що вони знайдуть велику користь, якщо IDE підтримують їх (Microsoft!). Як тільки люди знайдуть, що вони можуть ляпнути свої квіткові скриньки поруч і добре їх читати, вони будуть. Можливо, ви будете додавати більше коментарів до вихідного коду раптово (що може бути лише хорошою справою).

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

Недоліки: це може призвести до того, що ваш джерело буде виглядати погано, якби ряд рядків виглядав так, як вони були змінені, коли насправді було змінено лише 1 (якщо редактор зберігав файл із вкладками, перетвореними на пробіли). Або, якщо еластична вкладка була реалізована з одним символом (або, швидше за все, двома табличками), то перегляд джерела за межами редактора може виглядати погано.

Я думаю, що мені подобається ця ідея, але "вкладка" в кінці рядка розширює блок коментарів і вибудовує всі коментарі до наступних рядків (у яких розміщено подвійну вкладку) відповідно.


3

Ось як я це бачу: якби більшість популярних інструментів вже підтримували еластичні вкладки, багато людей використовували б їх. Те ж саме сталося з режимом навігації / редагування vi, з підсвічуванням синтаксису, а пізніше з Intellisense. У кожному конкретному випадку загальноприйнята мудрість полягала в тому, що вона не є корисною чи не потрібною, але вона втілилася в життя і знялася.

Звичайно, пружні вкладки мають відносно низький вплив. Більшість людей достатньо задоволені статусом, тому їх не хвилює. Подібні міркування застосовуються до багатьох ситуацій, коли деякі люди просто задоволені тим, що у них є, і не бачать причин переходити на щось більш досконале. Іншими словами, найбільша проблема з еластичними накладками - така ж, як і для практично будь-якої іншої гарної ідеї: їй потрібно отримати тягу.

Але це не означає, що функцію не можна приймати поступово. Кожна окрема мова програмування була прийнята поступово, навіть якщо вся команда вимагає нового компілятора та нового IDE, щоб почати користуватися нею. Те саме стосується кожної окремої архітектури обладнання та багатьох інших прикладів. Також не так, що відсутність інтеграції з існуючими інструментами є зупинкою показу: те саме стосується, наприклад, "уніфікованого-різного формату", який поступово замінив попередній менш читабельний формат, який, тим не менш, розумівся автоматизованими інструментами (наприклад, патч). Ці інструменти з часом були вдосконалені.

Я вдячний з питань інтеропу, про які згадували інші, але, незважаючи на них, напевно знайдуться команди (як і моя), які прийняли б це без вагань, в цілому. Зовнішні інструменти, такі як розрізнення, злиття тощо, спочатку не підтримують його, але ми зробимо все, щоб заохотити продавців включити цю функцію. Ось так завжди досягався прогрес. Це вимагає певних болів для тимчасового перехідного періоду, але, врешті-решт, воно того варте.


Аргумент C проти C ++ здається дещо помилковим. Хоча це може бути правдою, що це стосується "деяких людей" (як ви правильно сказали), є очевидні причини дотримуватися C або надавати перевагу C ++ залежно від ситуації. Розмір часу C ++, що є одним із них, у налаштуваннях за замовчуванням.
хайлем

Я з хайлем. Ваша думка була б більш чутною без порівняння С порівняно з С ++. Вони зовсім інші мови. На мій погляд, C призначений для програмування систем та інших низькорівневих робіт, де потрібно багато контролю (наприклад, VM). C ++ - це більше для додатків середнього рівня, де абстрагування корисно для управління складністю (простори імен, контейнери STL та алгоритми, шаблони), але продуктивність все ще викликає занепокоєння (ігри є найбільш видимим прикладом).
Джон Перді,

@haylem: Дякую за відгук. Я видалив посилання на C / C ++.
Тімві

@JonPurdy: Дякую за відгук. Я видалив посилання на C / C ++.
Тімві

2

Найбільша проблема, з якою я мав би бути, - це непослідовний інтервал у всій документації. Я знаю, що як програміст мені буде дратуватися бачити цикл або якщо оператор при "стандартному" відступі, а потім помічати його в різних відступів. Особисто я знаю, що мені подобається бачити всі фігурні фігурні фігурні дужки в документації, а не лише в коді коду, на який я дивлюся.

В цілому, я думаю, що це гарна ідея, але особисто мені це не сподобається.


1

Я щойно спробував реалізувати 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.
}

Я скажу, що діалекти Lisp, такі як 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, де пробіл є функціональним та / або візуально корисним. Еластичні вкладки були створені спеціально для того, щоб бути корисними, не вимагаючи окремої утиліти відступу, але, очевидно, це не для всіх мов програмування.


0

Emacs вже обробляє відступ у присутності незакритих дужок, і автоматично вирівняє wilma з fred . Я поняття не маю, чому Eclipse не робить так. Гаразд, у мене є ідея, але це непросто.

Ви можете змусити Emacs вирівняти коментар також без особливих проблем, але AFAIK ніхто, крім вас, цього ніколи не хотів.


2
Я можу лише трактувати ваше останнє речення як тролінг, оскільки, очевидно, щонайменше один хлопець хотів, щоб це було досить погано, щоб створити добре аргументовану сторінку, реалізацію Java та GIF, щоб показати, чому це добре. Якщо ви прочитаєте відповіді, то виявите, що Нік теж не один. О, зачекайте, подивіться і тут .
Роман Старков

До речі, чи Emacs повторно відступає wilmaпід час редагування, наприклад, зміни довжини назви функції? Якщо це так, це досить близько до того, що роблять еластичні вкладки.
Роман Старков

@romkyns: Я не хочу бути тролінг, я просто мав в виду , що я ніколи не бачив , що стиль коментаря відступів в в EMACS. Як правило, EMACS не повторно відступає кілька рядків під час введення, але це також може бути змінено.
кевін клайн
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.