소스 파일 끝에 빈 줄을 두는 것이 왜 권장됩니까?

소스 파일 끝에 빈 줄을 두는 것이 왜 권장됩니까?

---

일부 코드 스타일 도구는 이것을 권장하며 빈 줄 누락에 대해 경고하는 유닉스 명령 줄 도구를 본 것을 기억합니다.

빈 줄이 추가 된 이유는 무엇입니까?

---

텍스트 파일의 마지막 데이터 행이 줄 바꿈 또는 캐리지 리턴 / 줄 바꿈 조합으로 끝나지 않으면 이전 도구가 제대로 작동하지 않습니다. 대신 ^ Z (eof)로 끝나는 라인을 무시합니다.

---

두 개의 텍스트 파일을 함께 연결하려고하면 첫 번째 파일이 줄 바꿈 문자로 끝나면 훨씬 더 행복해집니다.

---

텍스트 편집기에서 파일 끝으로 이동할 때 커서 위치가 더 좋다는 사실 외에도.

파일 끝에 줄 바꿈이 있으면 파일이 잘리지 않았는지 간단히 확인할 수 있습니다.

---

왜 목록에 후행 쉼표를 사용할 수 있습니까? 와 같은 이유에 따라 파일에 추가하면 깔끔한 diff에 대한 인수를 만들 수도 있습니다 .

다음은 링크 된 리소스에서 복사 (그리고 약간 잘라 내기)되었습니다.

바꾸다:

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

에:

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

diff의 한 줄 변경 만 포함합니다.

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

후행 쉼표를 생략하면 혼란스러운 여러 줄 차이를 이깁니다.

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

---

파일 끝에 빈 줄이 나타나서 입력 스트림에서 표준 판독 값이 읽기 종료 시점을 알 수 있도록합니다. 일반적으로 EOF를 반환하여 종료에 도달했음을 나타냅니다. 대부분의 언어는 EOF 마커를 처리 할 수 ​​있습니다. DOS에서 EOF 마커는 F6 키 또는 Ctrl-Z, * nix 시스템의 경우 Ctrl-D였습니다.

전부는 아니더라도 대부분의 경우 실제로 EOF 마커까지 직접 읽으므로 런타임 라이브러리의 입력 읽기 기능은 더 이상 읽기를 중지해야 할 시점을 알 수 있습니다. 추가 모드로 스트림을 열면 EOF 마커가 지워지고 그 시점에 EOF 마커가 삽입 될 때까지 명시 적으로 호출 될 때까지 EOF 마커가 지워지고 그 이후에 기록됩니다.

오래된 도구는 빈 줄과 EOF 마커가 필요했습니다. 오늘날 도구는 빈 줄을 처리하고 무시할 수 있습니다.

---

또한 파일을 수정하고 파일 끝에 일부 코드를 추가하면 diff (적어도 표준 구성의 git diff)는 마지막 행을 변경했지만 실제로 수행 한 유일한 작업은 개행 기호를 추가 한 것으로 나타납니다. 따라서 cvs 보고서는 덜 편리해집니다.

---

일부 언어는 입력 파일을 입력 줄로 정의합니다. 여기서 각 입력 줄은 캐리지 리턴으로 끝나는 일련의 문자입니다. 해당 문법이 정의되어 있으면 파일의 마지막 유효한 행도 캐리지 리턴으로 종료해야합니다.

---

텍스트 파일의 정의 때문입니다. 유닉스 환경에서 새 텍스트 파일을 만들 때 해당 파일의 내용은 줄 바꿈 문자 '\ n'입니다.

이것이 없으면 파일은 실제로 텍스트 파일로 식별되지 않습니다. 이제이 텍스트 파일에 코드를 추가 하면 텍스트 파일 자체 를 정의하는 이 새 줄을 제거하지 않습니다 .

참고 URL : https://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-a-source-file