To jest satyryczny protokół fikcyjnego laboratorium, a nie opis przeprowadzonego badania. Żaden z poniższych obrazów nie stanowi wyniku pomiaru. Prawdziwe są natomiast ligatury programistyczne, krój Fira Code oraz ustawienia edytora, które pozwalają je zobaczyć.
Materiał badawczy: dwa znaki, jeden kostium
Na stanowisku umieszczamy fragment kodu zawierający ->. Zależnie od języka programowania i kontekstu ten ciąg może pełnić rozmaite funkcje; tutaj interesuje nas jego wygląd. Myślnik i znak większości mogą na ekranie wystąpić osobno albo przybrać wspólną, przypominającą strzałkę formę. Ta druga możliwość to przykład ligatury programistycznej.
Ligatura jest sposobem wyświetlenia określonej sekwencji znaków. Fira Code, darmowy krój o stałej szerokości znaków, zawiera ligatury dla popularnych kombinacji używanych w programowaniu. Jego dokumentacja podaje między innymi ->, <= i :=. To dla nas materiał niemal idealny: na stole leży interpunkcja, a protokół pozwala udawać, że obserwujemy zjawisko wymagające białego fartucha.
Najważniejsze zastrzeżenie zapisujemy na teczce grubym markerem: zmiana wyglądu nie zmienia kodu w pliku. -> pozostaje ciągiem dwóch znaków, a nie staje się automatycznie osobnym znakiem strzałki Unicode. Kompilator nie dostaje nowego operatora tylko dlatego, że ktoś wybrał bardziej ozdobny płaszcz dla starego. Również pokazanie dwóch kresek jako jednego kształtu nie usuwa obowiązku przeczytania obu kresek.
Próba kontrolna: oczy kontra edytor
Proponujemy doświadczenie myślowe. Otwórz ten sam fragment w edytorze z ligaturami, a potem obejrzyj go bez nich. W pierwszym widoku ciąg może wyglądać jak zgrabny symbol, w drugim znów widać jego części. Treść pliku pozostaje taka sama, o ile podczas porównania jej nie edytujesz. Nie mierzymy czasu reakcji ani nie ogłaszamy zwycięstwa którejkolwiek wersji.
W Visual Studio Code można włączyć ligatury ustawieniem "editor.fontLigatures": true, po zainstalowaniu i wybraniu obsługującego je kroju, na przykład Fira Code. Wyłączenie tej opcji pozwala porównać wygląd bez ligatur. Szczegóły prezentacji zależą od kroju, jego ustawień i aplikacji: sama obecność nazwy fontu nie gwarantuje, że każdy możliwy ciąg otrzyma widowiskowy kostium.
Warto odróżnić edytor od wbudowanego terminala. To osobne obszary interfejsu i nie należy zakładać, że zmiana ustawienia jednego automatycznie urządzi drugi. Nasze fikcyjne laboratorium oznacza je etykietami „tu piszę kod” oraz „tu również piszę, ale z nieco innym wyrazem twarzy”. Etykiety nie są konieczne do działania programu, choć poprawiają dyscyplinę szuflady.
Przy przełączaniu widoków nie zmieniaj jednocześnie kroju, rozmiaru i koloru tła, jeśli chcesz przyjrzeć się właśnie ligaturom. Porównanie będzie wtedy łatwiejsze do interpretacji: różnica w wyglądzie nie zleje się z kilkoma innymi zmianami. Nie jest to przepis na eksperyment naukowy, lecz domowy sposób na poznanie własnych ustawień. W naszym protokole kartka z instrukcją leży obok kubka, który pełni funkcję wyłącznie kubka.
Rozróżnianie podejrzanych osobników
Ładna ligatura nie jest dowodem, że zapis znaczy to, co czytelnik sobie dopowiedział. = i == nie są tym samym ciągiem, a znaczenie każdego zależy od używanego języka i miejsca w kodzie. Podobnie -> i => różnią się pierwszym znakiem. Jeśli krój uwydatnia ich kształty, porównanie może być wygodne; jeśli ktoś woli widzieć składniki osobno, ma prawo wyłączyć tę ozdobę.
Przy code review dobrze jest sprawdzać nie tylko ogólny zarys, ale też znaki tworzące operator. W razie wątpliwości pomocne bywa chwilowe wyłączenie ligatur albo podejrzenie tekstu w środowisku, które ich nie stosuje. Można też zaznaczyć i skopiować interesujący fragment do zwykłego pola tekstowego. To kontrola zapisu, nie magiczny test poprawności programu: wynik nadal trzeba interpretować w kontekście języka.
Dokumentacja Fira Code opisuje również warianty niektórych znaków. Ich dostępność i sposób włączenia zależą od używanej aplikacji. Taki wybór może pomóc dopasować wygląd do własnych potrzeb, ale nie zastępuje rozsądnego rozmiaru tekstu ani uważnego czytania. Laboratorium odmawia wystawienia certyfikatu na samą obecność przekreślonego zera.
Protokół przeglądu w warunkach domowych
Do testu wybierz krótki fragment, który znasz, najlepiej bez poufnych danych. Zapisz go, obejrzyj w obu wariantach i porównaj, czy rozpoznajesz poszczególne operatory. Zwróć uwagę na podobne sekwencje, takie jak -> oraz =>, a także na znaki otaczające je w rzeczywistym fragmencie. Kontekst często mówi więcej niż efektowna strzałka.
Jeśli pracujesz z innymi osobami, nie musisz narzucać im jednego kroju. Współpracownicy mogą oglądać ten sam zapis przy różnych ustawieniach, więc komentarz do przeglądu powinien odnosić się do tekstu i jego znaczenia, a nie wyłącznie do kształtu widocznego na twoim ekranie. Zdanie „sprawdź operator =>” jest czytelniejsze niż „popraw tę ładną strzałkę”.
Przy omawianiu błędu dobrze też podać nazwę pliku i wskazać fragment, którego dotyczy uwaga. Zrzut ekranu może pokazać, jak widzi go autor komentarza, ale nie powinien być jedynym sposobem przekazania zapisu. Osoba po drugiej stronie może używać innego powiększenia lub kroju. W fikcyjnym laboratorium nazywamy to zasadą wspólnej próbki: wszyscy rozmawiają o tych samych znakach, nawet gdy patrzą na nie przez różne typograficzne okulary.
Nie będziemy rozstrzygać, czy ligatury przyspieszają pracę ani komu pomagają. Takie twierdzenie wymagałoby rzetelnego badania, którego tutaj nie przeprowadziliśmy. Możemy natomiast postawić skromny wniosek: krój wpływa na to, jak widzimy zapis, a nie na to, jakie znaki zapisano. Protokół zamykamy, odkładając strzałkę do pudełka z napisem „wygląd”. Myślnik i znak większości pozostają w pliku osobno, nawet jeśli nadal wyglądają na nierozłącznych.