Jak ktoś kod pisze w vimie to moze jest to problem ale każde racjonalne IDE ogarnie to za ciebie. R studio to nie jest racjonalne IDE, tylko parodia

@panek mogę ustawić żeby mi to ogarniał za mnie. Pytanie tylko po co?

Zaszłość historyczna, kompatybilność wsteczna. To samo z tym że linia kodu powinna mieć max 80 znaków. Powoli się to zmienia ale postępuje i za parę lat będzie po problemie

@panek popraw mnie proszę jeśli się mylę, ale co ma do tego kompatybilność wsteczna? Kompilator ten kod skompiluje tak samo, niezależnie czy są tam taby, czy spacje (obchodzą go tylko i wyłącznie średniki, lub miejsca gdzie się kończy dana linia), dlatego jedną z metod to optymalizacji ładowania stron, jest przesyłanie skryptów w javascriptcie pozbawionych jakichkolwiek znaków nowej linii (tym sposobem kod jest nieco mniejszy, i ładuje się nieco szybciej), co udowadna że przynajmniej dla interpretera JS, taby lub spacje na początku linii nie mają znaczenia

@redve no i mówimy na to "indentacja" a nie "indencja", albo po prostu "wcięcia"

@size dzięki, pomyliło mi się z angielskim "indention"

@redve np interpreter pythona wy⁎⁎⁎ie ci wyjątek jak w jednym projekcie używasz różnych metod robienia wcięć. Trzeba by było całe codebase-y aktualizować na taby, a to jest kłopot taki sam jak z uruchamianiem wstecznie np blacka do formatowania kodu w jednakowy sposób.

@panek akurat w pythonie to zrozumiałe, bo tam wcięcie jest elementem składni języka. Niemniej, jak już wspomniano powyżej, współczesne IDE sobie z tym radzą bez problemów i generalnie ten temat stanowi już pieśń przeszłości w większości przypadków. Polecam autoformatowanie w edytorach i włączenie "ignore white spaces" w diffach gita.

-Mogę ustawić "szerokość" tabów na taką...

-Możesz sobie ustawić edytor...

@redve Powód: byś nie musiał. Nie musiał dostosowywać IDE, edytora, czy czego używasz, za każdym razem. Mając kilka projektów każdy musiałbyś dostosowywać pod siebie i odwrotnie: inni musieliby odwracać twoje ustawienia pod siebie. Taby mogą inaczej wyglądać (różnej wielkości wcięcia) na różnych systemach i w różnych edytorach. Spacje (podobno) wyglądają wszędzie tak samo. Nie trzeba nic robić by wszędzie wyglądało tak samo. Jak ci nie pasują taby, ustaw sobie IDE by automatycznie zmieniało na spacje.

@Meverth no spoko, a co jeżeli wolę wcięcie na 8 spacji lub na 2, zamiast na 4?

Jeżeli każdy używałby tabów, i miałby ustawioną taką szerokość jaką lubi, to nikt nie musiałby nic dostosowywać. U każdego 1 tab, ma szerokość 1 taba. Jeżeli każdy używałby wcięcia tabem szerokości 4 spacji, to:

1. ustawianie IDE żeby podmieniało je na spacje byłoby zbędne. Wszystko ustawiasz raz przy instalacji IDE
   

2. osoby które preferują inną szerokość wcięcia nie mają problemu
   

3. same pliki z kodem fizycznie byłyby mniejsze (zakładając że 1 znak przechowujemy na 1 bajcie, na każde 10k linii kodu oszczędzamy ~29kB pamięci)

@redve oprócz kompilatora jest cała masa innych tooli, którymi jednak posługuje się człowiek. narzędzia do code review czy statycznej analizy kodu mogą zwijać wiersze albo wyświetlać poziome paski przewijania dla szerszych linii. Sam jestem za tabulatorami właśnie dlatego, że nie wyglądają tak samo. zazwyczaj pracuję na monitorze 1080p, ale czasami fragment kodu wstawiam w prezentację (czy kawałek pseudokodu w bloczek), a czasami biorę tablet i idę do labolatorium ściągnąć logi. wszystkie aplikacje dostosowują się do ekranu, ale kod ma wyglądać wszędzie tak samo? trochę bez sensu...

@redve to ustal z zespołem. Grunt by wszyscy mieli te same ustawienia.

@redve czasami chcesz inne wcięcie, niż 4. Na przykład

____if x == 4

______&& y == 5

wtedy masz mix tabów i spacji. A jeśli w kodzie do ciebie nie przemawia, to masz jeszcze komentarze:

____/* Bla bla bla pierwsza linia ma n wcięć (np. 2 taby lub 8 spacji)

_____* A druga potrzebuje tyle, co pierwsza + jedną spację

_____*/

Ale ogólnie, to jest to tak nieistotne, że polecam po prostu uświadomić sobie, że to nieistotne i jeśli większość używa 4 spacji, to używać 4 spacji. Do tego najlepiej jakiś automatyczny format, najlepiej na defaultowych lub prawie defaultowych settingach, wtedy wszyscy są nieszczęśliwi i jest po równo.

Bo serio, czy dasz klamrę w tej samej linii, czy niżej, czy z wcięciem, czy bez, to jest na maksa drugorzędna sprawa.

Aha, jeszcze jedno: są ludzie, jest ich bardzo wielu, w tym ty, którzy czytają obcy kod częściej, niż piszą swój nowy. Zakładam tu, że ty sprzed 2 tygodni jesteś dla dzisiejszego siebie obcą osobą.

@sasik520

Aha, jeszcze jedno: są ludzie, jest ich bardzo wielu, w tym ty, którzy czytają obcy kod częściej, niż piszą swój nowy. Zakładam tu, że ty sprzed 2 tygodni jesteś dla dzisiejszego siebie obcą osobą.

Miałem na myśli, że muszę spojrzeć z dokładnie taką samą indencją jak drugi programista, a nie w ogóle przeczytać czyiś kod

@redve Różne edytory wyświetlają różnie taby. Źle skonfigurowany edytor prowadzi albo do problemów z systemem kontroli wersji po przeformatowaniu kodu za jego pomocą (dziwne diffy), albo do dziwnie wyglądającego kodu (inaczej niż u wszystkich). Można oczywiście stwierdzić, że to problem danego programisty, że sobie nie potrafi skonfigurować edytora, ale lepiej po prostu używać spacji i nie tracić czasu na problemy u ludzi z dziwnymi konfiguracjami, albo juniorów którzy nie potrafią takiej konfiguracji ogarnąć.

Poza tym niektóre webowe narzędzia wyświetlają taby dziwnie i nie da się tego zmienić - na przykład GitHub przez długi czas wyświetlał taby o szerokości 8 spacji.

To samo tyczy się różnych tooli CLI - mix tabów i spacji może powodować w nich problemy.

PS: Tak dygresyjnie, w przypadku Rusta standaryzacja w obrębie całego ekosystemu to jego ogromna zaleta. Nie tylko w kontekście formatowania kodu, ale wszystkiego.