Czytałem Code Complete, aw rozdziale poświęconym układowi i stylowi przewidywał, że edytory kodu użyją pewnego rodzaju formatowania tekstu sformatowanego. Oznacza to, że zamiast kodu wyglądającego tak

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.

może wyglądać mniej więcej tak:

Procedura ResolveCollisions

Wykonuje rozdzielczość kolizji a posteriori za pomocą algorytmu podziału przestrzennego

Parametry

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Zmienne lokalne

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

    DoStuff();

Widziałem kolorowanie i podświetlanie składni, a nawet kolorowanie w nawiasach, ale nic, co wyglądałoby tak w rzeczywistym kodzie. Zastanawiałem się, czy coś takiego kiedykolwiek istniało, a może zdecydowano, że nie przyniesie on wystarczających korzyści lub że był to całkowicie zły pomysł.

Czy ktoś z was widział już wcześniej tak sformatowany kod lub wiedział, czy pomysł był kiedykolwiek rozważany i ostatecznie odrzucany?

Nie ma technicznego powodu, abyś nie mógł. Jeśli edytory tekstu potrafią wyróżniać składnię, równie łatwo mogą zmienić inne aspekty wyświetlania, aby podświetlić kod.

Jednak jedną rzeczą jest, aby to, co jest pisane, zmieniało kolory, gdy redaktor domyśla się, co piszesz. Nagłe zmienianie rozmiaru tekstu i przeskakiwanie podczas pisania byłoby naprawdę nieznośne.

Jednak w przypadku wyświetlania „statycznego” kodu można łatwo upiększyć kod źródłowy. Na przykład weź dowolny przyzwoity konwerter source-> html i dodaj dowolne rozmiary czcionek i style do arkuszy stylów, a otrzymasz bogaty sformatowany kod.

Prosty powód: niezależność edytora / narzędzia.

Gdy uczynisz kodowanie „bogatym” - będzie ono powiązane z edytorem, którego użyłeś - lub z tymi, które potrafią zrozumieć bogaty kod. Wszystkie inne edytory, które nie są w stanie obsłużyć bogactwa, pokażą bełkot.

W tym samym stylu bogaty kod nie działałby dobrze z narzędziami różnicowymi. Na przykład, jeśli właśnie zmieniłeś formatowanie, diff pokaże różnicę, ale nie jest to nawet różnica, o którą najmniej się martwisz.

A co z kontrolą wersji? Jak by to powiedzieć, aby ignorował wszystkie zmiany w formatowaniu i wyświetlał pliki jako zmodyfikowane tylko wtedy, gdy nastąpiła jakaś „prawdziwa” zmiana.

Wreszcie wydaje mi się, że całym celem bogatego kodu jest czytelność - i do tego uważam, że lepsze (i więcej) komentarze, logiczne nazwy identyfikatorów i spójne wcięcia będą wystarczające.

Zasadniczo tekst programowania najlepiej traktować jako zwykły tekst - to, co widzisz, jest rzeczywistością. ( co jest również zgodne z Pythońską ideą jawnego lepszego niż niejawnego )

Być może bogato sformatowany kod się nie przyłapał, ponieważ nie jest to taki fajny pomysł. Osobiście nie podoba mi się to, co widzę w podanym przez ciebie przykładzie. Używam kolorowania i podświetlania składni, ale to formatowanie jest zbyt skomplikowane i zbyt odbiega od sposobu, w jaki przywykłem do pisania i pisania kodu.

Dlaczego nie istnieje? Nie ma na to zapotrzebowania / potrzeby.

Obecni redaktorzy są w stanie zaspokoić potrzeby programistów dzięki podświetlaniu składni i innym drobnym opcjom stylistycznym. Czy to już nie jest „tekst sformatowany”?

To już istnieje dla LaTeX w trybie AucTeX dla Emacsa. Tytuły sekcji mają większy rozmiar, indeksy górne i dolne są odpowiednio zmieniane, a nawet możesz mieć małe podglądy matematyki (i ewentualnie innych środowisk, takich jak Algorytmic).

Jest to w porządku dla LaTeX-a, ponieważ mapowanie kodu na wyjście jest zwykle znacznie prostsze niż w innych programach; Myślę, że w ogóle nie podobałoby mi się to w przypadku języków ogólnego przeznaczenia.

Inną rzeczą Emacs może zrobić, to zastąpić symbole jak ->i forallz →i ∀odpowiednio w Haskell. Nie ma powodu, aby tego rodzaju rzeczy nie można było rozszerzyć na formatowanie, jak sugerujesz, z wyjątkiem tego, że w Haskell nie jest to wcale konieczne.

Jakiś czas temu zadałem to pytanie dotyczące formatowania kodu, pytając, czy programiści chcieliby sformatować swój kod podczas pisania.

Moje pytanie dotyczyło tylko aspektu wcięcia w formatowaniu, ale niektóre odpowiedzi mogą ogólnie dotyczyć formatowania kodu. Ogólny sentyment w odpowiedziach sugeruje, że programiści są przeciwni utracie absolutnej kontroli nad sposobem reprezentowania ich kodu.

Moje osobiste doświadczenia były zupełnie inne. Chociaż zwykle używam publicznie dostępnych narzędzi, czasami muszę pisać XSLT we własnym edytorze na zamówienie. Ten edytor formatuje kod podczas pisania, wcinając lewy margines, dzięki czemu nie mam problemów z niechcianymi spacjami (znaczącymi w XSLT) i pozwala mojemu kodowi zawijać słowa, a jednocześnie nadal formatować. Uważam to za całkiem naturalne, styl formatowania jest kontrolowany przez kontekst i pozycję samych linii (doświadczenie jest szczególnie satysfakcjonujące, gdy używa się urządzeń wejściowych wrażliwych na dotyk).

Jeśli XSLT nie jest dobrze wyważony, formatowanie faktycznie pomaga pokazać, gdzie leży problem. Dostosowanie przesunięcia kodu w poziomie zajęło trochę czasu podczas pisania, ale nie jest to dla mnie rozproszeniem. Odkryłem jednak, że funkcje formatowania, które miały wpływ na pionowe odstępy mojego XSLT, sprawiły, że edytor był prawie bezużyteczny, więc je wyłączyłem.

Wracając do twojego pytania, myślę, że powodem, dla którego bogate formatowanie kodu nie jest bardziej powszechne, jest to, że zmiana percepcji w świecie programowania zajmuje dużo czasu. Nadejdzie jego czas, być może zbiegający się z czasem, w którym edycja kodu odbywa się głównie bez klawiatury.

Również w więcej niż kilku językach (Haskell, Ruby, Python, Erlang, CoffeeScript i kilka innych) wcięcie jest ważne. Więc jeśli zmieniasz rozmiary czcionek, może być bardzo trudno to rozgryźć.

Głównie jego tradycja. Programuję zawodowo od prawie 20 lat i podejrzewam, że doprowadziłoby mnie to do szału. Piszę książki w Emacsie lub VI z docbook, więc nie jestem fanem WYSIWIG

Robi to CWEB Knutha, ale działa tylko dla C / C ++ i Pascala. - Powinieneś na to spojrzeć… jest całkiem fajnie. Istnieją dwa programy: ctanglei cweavektóre łączą / oddzielają pliki CWEB odpowiednio w TeX i C.

Czy ktoś z was widział już wcześniej tak sformatowany kod lub wiedział, czy pomysł był kiedykolwiek rozważany i ostatecznie odrzucany?

Pewnie. Xcode obsługuje style poza prostym kolorem dla różnych składni:

Minęło sporo czasu, odkąd go użyłem, ale myślę, że Metrowerks CodeWarrior również wspierał stylizowany tekst, i to było ponad 10 lat temu.

Jednak nie chcesz przesadzać ze stylami - każdy tekst, kod źródłowy lub inny sposób może być trudniejszy do odczytania, gdy style różnią się zbyt mocno. W szczególności myślę, że mieszanie rozmiarów jest rozpraszające, a wszystko, co powoduje, że kolumny nie ustawiają się w linii, jest denerwujące. Jest powód, dla którego większość programistów nadal używa czcionek o stałej szerokości.

Innym pytaniem jest, czy stylizowany tekst powinien być używany jako część samej składni języka. Na przykład, czy kompilator powinien wykorzystać fakt, że jakiś tekst jest stylizowany na określony sposób, aby określić, że tekst jest deklaracją funkcji? Na początku może się to wydawać szalone, ale języki takie jak Python i Fortran już używają wcięć jako składni. Niemniej jednak myślę, że bardziej prawdopodobne jest, że nadal będziemy postrzegać styl oparty na składni, a nie na odwrót. Istnieje wiele korzyści płynących z możliwości używania zwykłego tekstu (prostsze kompilatory, niezależność platformy, preferencje programisty), a inne tradycje ewoluowały, aby kod był czytelny przy braku stylów (wcięcia, puste linie, znaki znaczników i funkcje edytora, takie jak składanie kodu i menu nawigacyjne).

Myślę, że bogate formatowanie kodu źródłowego nie jest zbyt popularne, ponieważ jest przeznaczone do wprowadzania informacji, gdzie struktura i znaczenie są znacznie ważniejsze (i łatwiejsze do wpisania). Czcionka, dodatkowe specjalne symbole i białe spacje po prostu dodają niepotrzebnego hałasu wizualnego. Może to być odpowiednie dla wygenerowanej dokumentacji.

Nigdy nie kończy się wojna płomieni na ten sam temat w składaniu świata między tymi, którzy preferują edytory WYSIWYG (jak MS Word), a systemami takimi jak TeX (LaTeX).

Zasadniczo nie ma ostatecznej odpowiedzi. Wszystko zależy od narzędzi, przypadków użycia i osobistych preferencji.

Narzędzia takie jak Doxygen lub JavaDoc już formatują bogate formatowanie tekstu. Dodają również hipertekst do celów przeglądania. Nie trzeba wstawiać specjalnych tagów do podstawowego formatowania.

To jednak nie jest WYSIWYG.

Boję się powiedzieć, że to istnieje.

W przeszłości pracowałem nad jakimś kodem Centura (znanym również jako Gupta lub SQL / Windows - stary kod „ 4GL ”). Naprawdę nie było możliwe edytowanie kodu Century w standardowym edytorze, takim jak Notatnik, do wymaganego poziomu formatowania.

Chociaż może się wydawać, że dobrym pomysłem byłoby sformatowanie takiego pliku źródłowego, uważam, że rozwijanie go jest dość restrykcyjne i bolesne.

Ponadto formatowanie często powodowało problemy podczas scalania kontroli źródła.

Oprócz innych odpowiedzi chciałbym podkreślić, że oprócz trudności technicznych związanych z używaniem bogatego formatowania, jest to również przedmiot osobistych preferencji.

Jeśli edytujesz zwykły tekst, możesz wybrać czcionki i kolory, które ci się podobają, i są one ustawiane automatycznie. Jeśli chcesz edytować tekst sformatowany, co jeśli nie lubisz określonych kolorów i czcionek ustawianych ręcznie?

Myślę, że dzieje się tak, ponieważ nikt jeszcze nie rozdzielał odczytu kodu i pisania kodu. Przynajmniej nie staje się głównym nurtem. Czasami musisz przeczytać kod, którego dotknąłeś dawno temu lub kod stworzony przez innych programistów. Prawdopodobnie będziesz musiał dużo czasu poświęcić na zmianę jednego bajtu w tym źródle. Może to być tryb „odczytu”, w którym można zrobić wszystko, co jest potrzebne do łatwiejszego zrozumienia (rozmiar czcionki, formatowanie, podskrypt, superskrypt itp.). Gdy będziesz gotowy, redaktor może przełączyć się w tryb „zapisu” i być mniej restrykcyjny i bardziej przestrzegać „zasady najmniejszego zaskoczenia”