Estetyka kodu: Tabulatory kontra spacje
Jedni wolą lato, inni zimę. Jedni wolą samochody, inni motory. Programiści mają swoją własną wojenkę: wcięcia powinny bazować na spacjach, czy tabulatorach?
Nie trzeba długo szukać, by trafić na dziesiątki postów, dyskusji, czy wręcz kłótni dotyczących estetyki pisania (czy raczej czytania) kodu. Sam nigdy się nad tym specjalnie nie zastanawiałem, używałem tabulatorów, bo irytowało mnie, gdy trzeba było mnóstwo razy klepać backspace. Teoretycznie działa shift+tab, ale w praktyce bywa z tym różnie: a to wcięcie ustawione jest na 4 spacje, a w kodzie nie wiedzieć czemu są 3, a to środowisko programistyczne ustawione jest na wcięcia tabulatorem i nie obsługuje zmniejszania wcięć spacjowych itd itd itd…
Temat wrócił do mnie dzisiaj, gdy pracując nad swoimi zadaniami nadziałem się na fragment kodu kolegi z pracy. Jako, że w naszym dziale panuje NetBeans, który domyślnie ma zaznaczoną opcję „expand tabs to spaces” (nie tak dawno wyszła nowa wersja i każdy ją instalował przeważnie zostawiając ustawienia standardowe), a ja pracowałem zdalnie z użyciem Eclipse, który z kolei domyślnie ma wcięcia tabulacyjne – pojawił się zgrzyt. Zaledwie kilka linijek kodu, ale za to z wcięciem na pół ekranu, shift+tab robiący wielkie nic = irytacja.
Wywiązała się w związku z tym dyskusja żeby ujednolicić wcięcia u każdego z pracowników naszego działu, a problem powstał gdy trzeba było zdecydować się czy używać tabulatorów czy spacji. Z ciekawości chciałem poczytać co o tym sądzą inni, więc wyguglowałem to i owo i okazało się, że trwa zażarta batalia zwolenników jednego i drugiego sposobu. Każda ze stron ma swoje argumenty i kontrargumenty, każdy ze sposobów ma swoje plusy i minusy.
Subiektywnie widzę to tak:
| ZALETY | WADY | |
|---|---|---|
| TABULATORY | swoboda interpretacji przez edytory, mniej klikania w przypadku zmniejszania wcięcia za pomocą backspace | bywa, że znikają przy kopiowaniu kodu między różnymi edytorami, są niepraktyczne w przypadku edycji plików z poziomu przeglądarki (jak np edytory w WordPressie) |
| SPACJE | wcięcia raczej wyglądają identycznie bez względu na edytor (nie uwzględniam sytuacji z czcionkami o niestałej szerokości znaków) | znacznie zwiększają rozmiar dokumentu (126 linii kodu z tabulatorami daje 3330 bajtów, ten sam kod z 4 spacjami zamiast tabulatora to już 3951 bajtów), w przypadku niekompatybilności edytorów można się zajechać czyszcząc czyjeś spacje |
Zdaję sobie jednak sprawę, że nikogo nie przekonam (zresztą nawet nie mam zamiaru) do jednego, czy drugiego sposobu. Jeśli ktoś już ma swoje przyzwyczajenie wcięciowe, to mało prawdopodobne, by coś w tym względzie zmieniał…
ALE! Czyżby? A gdyby tak standardem stała się „elastyczna tabulacja”? Trafiłem dziś na tę stronę i pomyślałem: to tak oczywiste, czemu nikt na to nie wpadł dawno temu (autor, Nick Gravgaard, wymyślił to wprawdzie już w 2006, ale pisząc dawno temu mam na myśli jeszcze starsze czasy)? Gdyby tak czołowe środowiska programistyczne jak Dreamweaver, Eclipse czy NetBeans wprowadziły takie rozwiązanie ile by to mogło ułatwić… Nie ukrywam, że jestem pod wrażeniem pomysłu samego w sobie, jak również zabrania się za praktyczną stronę tego przedsięwzięcia przez Nicka Gravgaarda – stworzył aplet Java demonstrujący działanie elastycznej tabulacji, napisał wtyczkę do GEdit, do Eclipse (nie wydana, bo czeka na rozwiązanie buga) oraz do Visual Studio 2010 (w fazie beta). Dodać można, że pomysł został podjęty przez Google i zaimplementowany jako pakiet tabwriter dla języka Go.
Możemy sobie tylko życzyć szybkiej implementacji w wielu innych miejscach. Tylko? Nie, możemy też coś zrobić 🙂 Wystarczy zagłosować na bug zgłoszony przez Nicka – im więcej głosów, tym wyższy priorytet, tym szybsza naprawa, szybsza implementacja! A gdyby coś takiego posiadałby Eclipse, to zwolennicy innych IDE na pewno by pozazdrościli i również pracowaliby nad wdrożeniem tego w ich edytorach. Czego sobie i Wam życzę 😉
Kategoria:Programowanie
Oznaczone jako: dreamweaver, dyskusja, eclipse, elastic tabstops, gedit, IDE, kod, netbeans
Przekaż dalej:
w Google biją po łapkach za taby
mają swoje sensowne wytłumaczenie – różni ludzie korzystają z różnych edytorów, które różnie wyświetlają różne znaki ;P
chodzi mi o ich wewn standardy kodowania oczywiście 😉
Ja nie uważam żeby to był argument przeciw – w końcu jeśli ktoś woli tabulator na 2 spacje, to niech i mu się tak wyświetli, nawet jeśli autor oryginału miał ustawione 4. Ja to wręcz uznałem za zaletę. Oczywiście tabulacja jest dobra do wcięć jako takich, dla czytelności kodu, ale nie spisuje się za dobrze w wyrównywaniu tekstu np. w dokumentacji, gdy mamy:
@param type name description
bo to już faktycznie może się mocno rozjeżdżać gdy ktoś wyrówna mając 6 spacji na tabulator, a otworzy to ktoś mający spacje 2 🙂
Ale tak szybko skomentowałeś, że odnoszę wrażenie, że w ogóle nie przeczytałeś wpisu 😀
szybko czytam takie teksty, zwłaszcza że temat jest oklepany 😉
jednym z problemów jest właśnie liczba znaków na tabulator vs długość linii widoczna bez zawijania
ale to preferencje z Google, mi to w sumie wszystko jedno
PS trochę tak wygląda jakby programowanie w Javie Cię dopadło?
Czytasz szybko i pobieżnie 😉 Bo meritum wpisu tak naprawdę nie jest to czy lepsze są tabulatory, czy spacje – zresztą napisałem, że nie mam zamiaru nikogo przekonywać (bo też i do czego? sam nie mam jakiegoś zdecydowanego faworyta w tej batalii). Po prostu zastanawiam się jak to można rozwiązać i tu pojawia się kwestia tych "elastic tabstops" 🙂
PS: niestety nie, chociaż chętnie sam bym się do Javy dopadł żeby poznać 🙂
pominąłem bo imho nie warto
kluczowe jest aby kod był czytelny dla każdego kto go edytuje/czyta
– każdy musiałby to mieć w swoim środowisku, edytorze tekstowym (notatnik, vi, notepad++ itp.)
takie wynalazki można używać dla siebie, lub w małym teamie na krótki dystans – dlatego też mimo, że błyskotliwe to pominąłem milczeniem ;p
geekowo-nerdowa dyskusja na face – lame 😀
Ale to nie jest tak, że to jest coś, co działałoby tylko i wyłącznie tam, gdzie byłaby taka funkcjonalność. To jest zamiennik interpretowania tabulatora jako X spacji lub zwykłego wcięcia – zamiast tego znak tabulatora układałby fragmenty kodu w kolumny. Więc problem, o którym wspomniałem wcześniej by zniknął, bo wystarczyłoby dla
@param type name description
wstawić po jednym tabulatorze między słowa kluczowe i bez względu na to jak długie byłyby np nazwy zmiennych, to opisy układałyby się wyrównane względem siebie. Dobrze to widać na stronie autora, gdzie jest gif i aplet, w którym można się pobawić.
Czyli ci, którzy mieliby edytory z tą funkcjonalnością widzieliby dobrze, a reszta widziałaby zwykłe tabulatory, czyli też jako tako ułożony kod. Jak dla mnie to zawsze coś, a gdyby to w ogóle kiedyś zostało jakimś standardem i byłoby zaimplementowane wszędzie*, to w ogóle wypas 😉
* pojęcie względne ;p
no taa, ale w praktyce wychodzi, że "szczęśliwcy" mają "tabelkę" a reszta przez wielu nielubiane taby
do tego pije mój pierwszy komentarz – może zbytni skrót myślowy :/