Dlaczego zaleca się umieszczenie pustej linii na końcu pliku źródłowego?

232

Niektóre narzędzia w stylu kodu to zalecają i pamiętam, że widziałem niektóre narzędzia wiersza poleceń unix ostrzegające o brakującej pustej linii.

Jaki jest powód posiadania dodatkowej pustej linii?

language-agnostic coding-style eof

— Petteri Hietavirta
źródło

7

Niektóre narzędzia nie działają, jeśli plik nie kończy się na nowej linii. Różni się to od posiadania pustej linii na końcu (co byłoby 2 nowymi liniami).

— William Pursell

2

Masz na myśli pustą linię ( \n\n) czy nową linię \n?

— Ciro Santilli 郝海东冠状病六四事件法轮功

13

catplik w powłoce, a dowiesz się, dlaczego. Jeśli twój plik powoduje, że monit mojej powłoki pojawia się w innym miejscu niż to, w którym powinien być (na początku linii), prawdopodobnie cię nienawidzę. ;)

— ThiefMaster

2

Przeszedłem przez to stare pytanie i po prostu nie mogę uwierzyć, że każda pojedyncza odpowiedź próbuje usprawiedliwić błędy i wady innych narzędzi i systemów, mówiąc, że nowi koderzy powinni dodawać znaki, które nie mają żadnej wartości w samym kodzie. Porozmawiaj o 5 małpach w klatce! :-D

— Amos M. Carpenter

1

Lepsze (bardziej ogólne) odpowiedzi na ogólnie pliki tekstowe :: stackoverflow.com/questions/729692/...

— Ruben Bartelink,

188

Wiele starszych narzędzi źle funkcjonuje, jeśli ostatni wiersz danych w pliku tekstowym nie jest zakończony kombinacją znaku nowej linii lub znaku powrotu karetki / nowej linii. Ignorują tę linię, ponieważ zamiast niej jest zakończona ^ Z (eof).

— Ralph M. Rickenbach
źródło

1

Dziękuję za odpowiedź! Jakieś przykłady popularnych narzędzi, które mogą wykazywać takie zachowanie?

— Nick Merrill

8

@NickM Prawie wszystkie narzędzia wiersza polecenia POSIX / Unix, które wprowadzają tekst lub czytają plik tekstowy, zakładają koniec linii ( \n) na końcu pliku. Kilka edytorów tekstu, takich jak Vim i kilka kompilatorów (w szczególności C ++ i Python) będzie wyświetlać ostrzeżenia. (W przypadku C ++ standard wyraźnie tego wymaga.)

— greyfade

5

Więc mówisz ... to kult ładunku

— Jaykul

Mimo to możesz mieć tekst w ostatnim wierszu, pytanie wspomina o pustym wierszu \n\n.

— jinawee

57

Jeśli spróbujesz połączyć dwa pliki tekstowe razem, będziesz o wiele szczęśliwszy, jeśli pierwszy zakończy się znakiem nowej linii.

— użytkownik1809090
źródło

38

Oprócz tego, że jest to ładniejsza pozycja kursora, gdy przechodzisz na koniec pliku w edytorze tekstu.

Posiadanie nowego wiersza na końcu pliku zapewnia proste sprawdzenie, czy plik nie został obcięty.

— rsp
źródło

221

Plik może zostać obcięty, a ty nigdy nawet nie powrócisz

— Simon Nickerson

26

Można również argumentować za czystszymi różnicami, jeśli dodasz do pliku zgodnie z takim samym uzasadnieniem, jak Dlaczego przecinki końcowe są dozwolone na liście?

Poniższe elementy są kopiowane (i nieco przycinane) z połączonego zasobu:

Wymiana pieniędzy:

s = [
  'manny',
  'jack',
]

do:

s = [
  'manny',
  'jack',
  'roger',
]

dotyczy tylko zmiany jednowierszowej w różnicach:

  s = [
    'manny',
    'jack',
+   'roger',
  ]

To pokonuje bardziej mylącą różnicę między wierszami, gdy pominięto przecinek końcowy:

  s = [
    'manny',
-   'jack'
+   'jack',
+   'roger'
  ]

— Mathias Bak
źródło

Odpowiedzi zawierające tylko łącza nie są uważane za wartościowe w przypadku SO. Skopiuj odpowiednie informacje tutaj, zachowując atrybucję.

— isherwood

17

Pojawia się pusta linia na końcu pliku, aby standardowy odczyt ze strumienia wejściowego wiedział, kiedy zakończyć odczyt, zwykle zwraca EOF, wskazując, że osiągnąłeś koniec. Większość języków obsługuje znacznik EOF. Jest tam z tego powodu od dawna, pod DOS, znacznikiem EOF był klawisz F6 lub Ctrl-Z, dla systemów * nix był to Ctrl-D.

Większość, jeśli nie wszystkie, w rzeczywistości odczytuje aż do znacznika EOF, tak że funkcja odczytu ze źródła w bibliotece wykonawczej będzie wiedziała, kiedy przestać czytać dalej. Gdy otworzysz strumień w trybie Append, wyczyści on znacznik EOF i napisze obok niego, aż zostanie jawnie wywołane zamknięcie, w którym wstawi znacznik EOF w tym punkcie.

Starsze narzędzia oczekiwały pustej linii, a po niej znacznika EOF. W dzisiejszych czasach narzędzia mogą obsługiwać pustą linię i ignorować ją.

— t0mm13b
źródło

6

^ D nie był „znacznikiem EOF”. Naciśnięcie ^ D spowodowało, że powłoka zamknęła stronę zapisu potoku, z którego czytała grupa procesów pierwszego planu, tak że odczyt z tej potoki zwrócił EOF. Nie ma „znacznika EOF”.

— William Pursell

@William Pursell Pomyłkowo pomyliłeś * NIX i Windows. Starsze systemy Windows / DOS bezwzględnie używały znacznika EOF (26, 0x1a) osadzonego zwykle na końcu większości plików w celu zachowania zgodności ze starożytnym CP / M (kto do cholery używał CP / M po 1983 roku?). Inne „fajne”: \r\nzamiast \nwywołań DOS przy użyciu kombinacji ASCIIZ i ASCII $. Co gorsza, później w systemie Windows zwykle wstawia znak kolejności bajtów Unicode (BOM) na początku większości plików tekstowych. Cudowna „wyjątkowość”.

9

Również gdy zmodyfikujesz plik i dodasz kod na końcu pliku - diff (przynajmniej git diff w standardowej konfiguracji) pokaże, że zmieniłeś ostatnią linię, a jedyną rzeczą, którą faktycznie zrobiłeś - dodał symbol nowej linii. Tak więc raporty cvs stają się mniej wygodne.

— prijutme4ty
źródło

5

Niektóre języki definiują swój plik wejściowy za pomocą linii wejściowych, gdzie każda linia wejściowa jest ciągiem znaków zakończonych znakiem powrotu karetki. Jeśli ich gramatyka jest tak zdefiniowana, ostatnia poprawna linia pliku musi być zakończona również znakiem powrotu karetki.

— Damien_The_Unbeliever
źródło

3

Wynika to z definicji pliku tekstowego. Kiedy tworzysz nowy plik tekstowy w dowolnym środowisku unixowym, zawartością tego pliku jest nowy znak wiersza „\ n”

Bez tego plik nie jest tak naprawdę identyfikowany jako plik tekstowy. Teraz, gdy dodamy kod do tego pliku tekstowego, chodzi o to, aby nie usuwać początkowej nowej linii, która definiuje sam plik tekstowy .

— Victor Fernandes
źródło