Я читав Code Complete і в главі про макет і стиль він передбачив, що редактори коду використовуватимуть якесь форматування насиченого тексту. Це означає, що замість коду виглядає так

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

це могло виглядати приблизно так:

Порядок ResolveCollisions

Виконує післястеріальну роздільну здатність зіткнення за допомогою алгоритму просторового розподілу

Параметри

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Локальні змінні

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

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

Чи бачив хто-небудь із вас раніше формат кодового формату, чи знаєте, чи ідея колись була розглянута та врешті-решт відхилена?

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

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

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

Проста причина: незалежність редактора / інструменту.

Після того, як ви зробите код "багатим" - він буде прив'язаний до редактора, який ви використовували - або до тих, які можуть зрозуміти розширений код. Усі інші редактори, які не можуть впоратися з багатством, покажуть хитрість.

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

А як щодо контролю версій? Як би ви сказали йому ігнорувати всі зміни у форматуванні та бачити файли як змінені лише тоді, коли є якісь "реальні" зміни.

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

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

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

Чому його не існує? Немає попиту / потреби в ньому.

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

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

Це добре для LaTeX, оскільки відображення від коду до виводу, як правило, набагато простіше, ніж в інших програмах; Я думаю, що мені взагалі не сподобалося б це для більш загальних мов.

Інша річ, яку може зробити Emacs - це замінити символи, такі як ->і forallна, →і ∀відповідно в Haskell. Існує мало причин, що подібні речі не можуть бути поширені на формати, як ви пропонуєте, за винятком того, що це зовсім не потрібно в Haskell.

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

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

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

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

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

Також у кількох мовах (Haskell, Ruby, Python, Erlang, CoffeeScript та кілька інших) важливі відступи. Тож якщо ви змінюєте розміри шрифту, це може бути важко зрозуміти.

Переважно його традиція. Я займаюся професійним програмуванням майже 20 років, і я підозрюю, що це призведе до мене. Я пишу книги в Emacs або VI з docbook, тому я не шанувальник WYSIWIG

CWEB Knuth робить це, але це працює лише для C / C ++ та Pascal. - Ви хоч погляньте на це, хоча ... це дуже акуратно. Є дві програми: ctangleі cweaveякі об'єднують / розділяють файли CWEB в TeX і C відповідно.

Чи бачив хто-небудь із вас раніше формат кодового формату, чи знаєте, чи ідея колись була розглянута та врешті-решт відхилена?

Звичайно. Xcode підтримує стилі, що перевищують просте забарвлення для різних синтаксисів:

З давніх пір я його використав, але я думаю, що Metrowerks CodeWarrior теж підтримував стильовий текст, і це було 10+ років тому.

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

Інше питання полягає в тому, чи слід використовувати стилізований текст як частину самого синтаксису мови. Наприклад, чи повинен компілятор використовувати той факт, що деякий текст визначений певним чином, щоб визначити, що текст є декларацією функції? Спочатку це може здатися божевільним, але такі мови як Python та Fortran вже використовують відступи як синтаксис. Тим не менш, я думаю, що більш ймовірно, що ми продовжуватимемо бачити стиль, керований синтаксисом, а не навпаки. Існує велика кількість переваг, які спричинені можливістю використання простого тексту (більш прості компілятори, незалежність платформи, налаштування програмістів) та інші традиції розвинулися, щоб зробити код читабельним за відсутності стилів (відступ, порожні рядки, символи маркера та такі функції редактора, як складання коду та меню навігації).

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

Ніколи не закінчується вогненна війна з однією і тією ж темою в наборі світу між тими, хто віддає перевагу редакторам WYSIWYG (як MS Word), та системами, такими як TeX (LaTeX).

Загалом, остаточної відповіді немає. Все залежить від інструментів, випадків використання та особистих уподобань.

Інструменти, такі як Doxygen або JavaDoc, вже бездоганно форматують багатий текстовий код. Вони додають код гіпертексту, а також з метою перегляду. Не потрібно вставляти спеціальні теги для основного форматування.

Це не WYSIWYG, хоча.

Боюся сказати, що це існує.

Раніше я працював над деякими Centura (також відомими як Gupta або SQL / Windows - старий " 4GL" ") код. Насправді редагувати код Centura в стандартному редакторі, як це зробити блокнот, не вдалось до крайнього рівня необхідного форматування.

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

Крім того, форматування часто спричиняло проблеми при об'єднанні в керуванні джерелами.

На додаток до інших відповідей, я хотів би зазначити, що крім технічних труднощів у використанні насиченого форматування, він також є об'єктом особистої переваги.

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

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