Dlaczego końcowe białe znaki są tak ważne? [Zamknięte]

Końcowy biały znak jest wystarczającym problemem dla programistów, że edytory takie jak Emacs mają specjalne funkcje, które go podświetlają lub usuwają automatycznie, a wiele standardów kodowania wymaga wyeliminowania wszystkich jego wystąpień. Nie jestem jednak do końca pewien, dlaczego. Mogę wymyślić jeden praktyczny powód unikania niepotrzebnych białych znaków i jest to, że jeśli ludzie nie będą ostrożni, aby go uniknąć, mogą zmienić go między zatwierdzeniami, a wtedy różnice zostaną zanieczyszczone pozornie niezmienionymi liniami, tylko dlatego, że ktoś usunął lub dodano spację.

To już wydaje się dobrym powodem, aby tego uniknąć, ale chcę sprawdzić, czy jest w tym coś więcej. Dlaczego więc spacje końcowe są tak duże?

Powody, dla których jest to dla mnie ważne:

• Po naciśnięciu klawisza „End” spodziewam się, że kursor przejdzie na koniec wiersza (w zależności od używanego edytora i sposobu jego konfiguracji) i spodziewam się, że będę mógł od razu zacząć pisać. Jeśli kursor się tam pojawi i muszę usunąć 3 lub 4 znaki, to irytuje. Zwłaszcza jeśli jest niespójny w całym pliku (plikach).

• Gdy mam literały ciągów obejmujące wiele wierszy, końcowe białe znaki mogą powodować, że łańcuch wyjściowy będzie wyglądał niepoprawnie, gdy zostanie użyty.

Chociaż nie jest to ścisłe programowanie, białe znaki mogą poważnie zepsuć wprowadzanie danych, jeśli istnieje plik końcowy / wiodący w pliku, który zostanie przeanalizowany i użyty jako dane wejściowe do czegoś innego. Dzieje się tak najczęściej, gdy czysty, wygenerowany plik wejściowy zostaje zabrudzony przez osobę edytującą go w programie Excel lub coś, a następnie mogą się wkraść końcowe białe znaki (i inne problemy z formatowaniem).

Naprawdę nie lubię kończyć białych znaków, ale dokładny powód jest nieco niejasny.

Wydaje mi się, że źródłem tego uczucia nie jest programowanie, ale dziedzina wydawnicza. Czy zdarzyło Ci się kiedyś, że ktoś napisał dokument, który musiał zostać wpisany do publikacji? We wszystkich współczesnych publikacjach, szczególnie w przypadku korzystania z kolumn, zwyczajowo zdania mają następujące po sobie zdania w jednym akapicie, bez rozpoczynania nowego wiersza dla każdego zdania. Cóż, gdy występują końcowe białe znaki, potrzeba dużo więcej wysiłku, aby je poprawnie (wiele operacji wyszukiwania i zastępowania eliminujących podwójne spacje itp.).

Inne powody (w programowaniu), nie dobre powody, wiem, ale przeszkadzają mojej psychice podświadomości w tak irytująco intensywny sposób, że zmuszają mnie do jej wyeliminowania:

• Zajmuje więcej miejsca do przechowywania niż to konieczne
• Analizator składni będzie musiał pominąć dodatkowy znak bez uzasadnionego powodu podczas kompilacji
• Niektórzy redaktorzy mogą dodawać dodatkowy pusty wiersz, gdy WordWrap jest włączony, a końcowe miejsce nie pasuje

Tak tak wiem! Wiem, że to są śmieciowe powody. Nie jestem perfekcjonistą, ale ... no cóż, jestem?

Ostatnim powodem, dla którego mogę wymyślić, jest niespójny ruch kursora. Wydaje się, że kursor zwisa w cienkim powietrzu na końcu linii, każdy krok w prawo może spowodować jego upuszczenie lub zawisnięcie w nieznanym stopniu, po prostu czuje się niepewnie (jak te niewidzialne lub znikające bloki, które Super Mario zwykł skakać).

Prawdopodobnie mogę zdiagnozować szlak spacefobii?

Wiele z tych odpowiedzi prawie dotyka powodu, dla którego jest to dla mnie złe, ale w gruncie rzeczy: „łamie” edytory tekstu. Moje doświadczenie jest z vimem.

Vim jest tak zaprojektowany, że typowe akcje odwzorowują litery tak czysto, że nie musisz nawet myśleć o tym, jaką literę lub kombinację klawiszy uderzyć. Różne skróty klawiszowe pozwalają kursorowi przeskakiwać wokół tekstu tak szybko, że potrzeba tylko kilku naciśnięć klawiszy, aby dostać się tam, gdzie chcesz. Nawet rzeczy takie jak składanie bloków kodu są szybkie, ponieważ możesz nacisnąć END lub $, aby przejść do końca linii, gdzie kursor powinien zachodzić na {lub} lub (lub) lub coś - nie musisz przerywać przepływu myśli dostać pomysł na ekran.

Ale potem pojawia się trochę białych znaków i ruchy kursora nie są już przewidywalne. Twój proces pisania jest przerywany, ponieważ coś, czego nie widzisz, wpływa na to, dokąd zmierza kursor, więc musisz przerwać swój tok myślenia, aby wysłać go tam, gdzie powinien.

Zauważyłeś kiedyś, jak denerwują się ludzie, kiedy są naprawdę skupieni na zadaniu i ktoś im przeszkadza? Tak, znajdowanie końcowych białych znaków w najmniej oczekiwanym momencie jest dokładnie takie.

_{Na marginesie zauważyłem również, że ludzie, którzy nie dbają o końcowe białe znaki, używają myszy do nawigacji i są z tego powodu wolniejsi maszynistkami ...}

Nieoczekiwanie brakuje najbardziej oczywistej odpowiedzi: końcowe białe znaki mogą i będą powodować trudne do znalezienia błędy.

Najbardziej oczywistą sytuacją są łańcuchy wieloliniowe. Python, JavaScript i Bash to kilka przykładów języków, na które może mieć wpływ:

print("Hello\·
····World")

produkuje:

  File "demo.py", line 1
    print("Hello\
                 ^
SyntaxError: EOL while scanning string literal

który jest w jakiś sposób tajemniczy i trudny do rozwiązania, jeśli edytor nie jest skonfigurowany do wyświetlania białych znaków.

Choć podświetlanie składni może pomóc uniknąć takich przypadków, to jeszcze łatwiej nie mając tę kwestię na pierwszym miejscu, nie pozwalając spacje na końcu linii. Właśnie dlatego niektóre kontrolery stylu wyświetlają ostrzeżenie, gdy napotykają końcowe białe znaki, a niektóre edytory przycinają je automatycznie.

^{Ilustracja: Podświetlanie składni może pomóc w uniknięciu spacji końcowych w sytuacjach, w których może prowadzić do błędów, ale nie polegaj tylko na tym.}

Innym kontekstem, krótko wspomnianym w poprzedniej odpowiedzi , są dane przechowywane w plikach.

Na przykład pliki CSV zawierające końcowe białe znaki mogą powodować niespójność danych, co również jest bardzo trudne do wykrycia: parsery zgodne ze standardami przycinają białe znaki (standard wskazuje, że początkowe lub końcowe białe znaki są nieistotne, chyba że są ograniczone podwójnymi cudzysłowami), ale niektóre parsery mogą źle zachowywać się i utrzymywać białe znaki jako część wartości.

Inne niestandardowe formaty mogą szczególnie uwzględniać fakt, że białe znaki są częścią wartości, co prowadzi do spójnych, ale wciąż trudnych do debugowania sytuacji.

Niedawno spędziłem dzień na poszukiwaniu błędu, który okazał się nieoczekiwanym końcowym białym znakiem w danych.

Kiedy wybieram kod źródłowy programu, aby go skopiować i wkleić (lub usunąć), uważam, że nieco denerwujące jest wyświetlanie wszystkich nieregularnych dodatkowych białych znaków na końcu linii: ponieważ muszę czytać kod podczas jego wybierania , końcowa biała przestrzeń jest niepotrzebnym hałasem. Przykład (kropki oznaczają białą spację):

if (fp)........
{....
    fclose(fp);.
}
else
{.....
    prinft("File is NULL\n");
}..

Ten przykład jest sztuczny, ale widziałem dużo kodu, który wygląda tak.

Poza oczywistym problemem, że w niektórych przypadkach psuje parsowanie? Jak zauważył inny plakat, może powodować subtelne i trudne do prześledzenia błędy. Białe znaki nie zawsze są nieznaczne. W niektórych przypadkach końcowe białe znaki mogą znacznie zmienić znaczenie wiersza kodu lub danych.

W większości przypadków białe znaki służą do formatowania kodu dla ludzkich czytelników. Końcowe białe znaki mogą wskazywać na kilka rzeczy, w tym:

• Niekompletne oświadczenie;
• Brakujący komentarz;
• Błędna edycja; lub
• Niedbała edycja.

Dwa z nich mogą powodować nieprawidłowe funkcjonowanie, a inne mogą utrudnić zrozumienie kodu.

Istnieją języki programowania wrażliwe na białe znaki końca linii. Na przykład skrypt TCL wyświetli błąd, jeśli na końcu wiersza znajduje się spacja.